[Bug testsuite/34214] v5.5 make installcheck stalls on rlimit.exp on ubuntu 24.04.4 dual Xeon 6146.

[mike_itguy at Yahoo dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=34214

--- Comment #8 from Mike <mike_itguy at Yahoo dot co.uk> ---

TLDR: Thank you for these updates, although sadly the proposed fix did not work
for me - same symptom. But new information below might help.

I attached a zip file that contains systemtap.log and systemtap.sum
corresponding to the re run of `make installcheck` following rebuild with the
proposed fix, and further to my notes below.

I note that you used a VM running ubuntu 26.04,  i.e.  a newer kernel than mine
(24.04.4 LTS uses 6.8.0-124).

The older kernel might contribute to my symptom , but at this time I cannot
upgrade to 26.04.

Note: My 24.04.4 LTS kernel /proc/cmdline is:
BOOT_IMAGE=/boot/vmlinuz-6.8.0-124-generic
root=UUID=19505212-6290-4ac5-b73c-151ea4ef012e ro quiet splash ipcmni_extend
vt.handoff=7

The kernel parameter ipcmni_extend was necessary for an RDBMS that I use
(although not running at the time of the tests). I don't yet know if this
parameter influences the make installcheck results.

I cloned the repo on 13/June/2026, rebuilt/reinstalled/run make installcheck as
root. 
I can see that the source code files include the proposed fix, along with other
code changes post release 5.5.

The `make installcheck job` continues to stall seemingly during rlimit.exp.

The systemtap.log had this entry ( at the time of the 'hang'): "PASS: rlimit
unlimited" 

After more than one hour of no further output in the systemtap.log, I did the
following, which may help you:

 $ ps -ef | grep stap | grep -v grep

root       25927   20853  0 13:25 ?        00:00:02 [stap] <defunct>
root      346990   20853  0 13:48 ?        00:00:02 [stap] <defunct>
root     1872603   20853  0 14:36 ?        00:00:02 [stap] <defunct>
root     1967809   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     1968935   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     1969765   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     2034902   20853  0 14:52 ?        00:00:03 [stap] <defunct>
root     2052477   20853  0 14:53 pts/0    00:00:00 /usr/bin/stap
--rlimit-as=2000000000 -wp4
/home/user1/systemtap/systemtap/testsuite/systemtap.base/rlimit.stp

# strace -p 2052477
strace: Process 2052477 attached
futex(0x789b115af990, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2052572, NULL,
FUTEX_BITSET_MATCH_ANY
.
As root, I sent this stap process a kill -9 and the stap process *resumed* (did
not get killed as I expected), and then it continued to run to process the next
files in the testsuite . 

I left `make installcheck` running until the next "hang" which occurred whilst
processing systemtap/testsuite/systemtap.context/symfileline.stp.  The
systemtap.log had "FAIL: symfileline in pp()". 
The process information at this time was as below:



root@t7920:~# ps -ef | grep stap | grep -v grep
root       25927   20853  0 13:25 ?        00:00:02 [stap] <defunct>
root      346990   20853  0 13:48 ?        00:00:02 [stap] <defunct>
root     1872603   20853  0 14:36 ?        00:00:02 [stap] <defunct>
root     1967809   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     1968935   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     1969765   20853  0 14:46 ?        00:00:02 [stap] <defunct>
root     2034902   20853  0 14:52 ?        00:00:03 [stap] <defunct>
root     2883356   20853  0 17:44 ?        00:00:04 stap -d kernel -d
systemtap_test_module2
/home/user1/systemtap/systemtap/testsuite/systemtap.context/symfileline.stp
root     2884766 2883356  1 17:45 ?        00:00:11 [stapio] <defunct>
root@t7920:~# 


root@t7920:~# strace -p 2883356
strace: Process 2883356 attached
wait4(2884766, 




I could not tell what the stap process was waiting for (the defunct stapio
process maybe?) , so once again I sent it a sigkill, and this time the stap
process got killed as expected.  The defunct stap and stapio processes remained
( and is consuming cpu according to 'top' despite ps showing it as <defunct>) .
It would be useful to know if the symptoms share the same root cause.

-- 
You are receiving this mail because:
You are the assignee for the bug.