Hide Forgot
The gdb-5.3post-0.20021129.11 build spawns an attach1 process in the testsuite and it renders build machines and mass rebuild test machines unusable. The running kernel on the machine in question is kernel-2.4.20-2.47.1 (msw says the test suite does not behave this way with kernel-2.4.20-2.26, and that problem shows on 2.4.20-2.29 as well). Here are the details: [root@loki root]# ps auxwww | grep attach #500 2927 88.8 0.0 1480 244 ? R 02:11 658:33 /tmp/attach1.20553 [root@loki root]# cd /proc/2927 [root@loki 2927]# ls -l total 0 -r--r--r-- 1 500 500 0 Feb 12 14:33 cmdline -r--r--r-- 1 500 500 0 Feb 12 14:33 cpu lrwxrwxrwx 1 500 500 0 Feb 12 14:33 cwd -> /mnt/build/rebuildtest/rebuild/pkgs/gdb/build-i386-redhat-linux-gnu/gdb/testsuite (deleted) -r-------- 1 500 500 0 Feb 12 14:33 environ lrwxrwxrwx 1 500 500 0 Feb 12 14:33 exe -> /mnt/build/rebuildtest/tmp/attach1.20553 (deleted) dr-x------ 2 500 500 0 Feb 12 14:33 fd -r--r--r-- 1 500 500 0 Feb 12 14:33 maps -rw------- 1 500 500 0 Feb 12 14:33 mem -r--r--r-- 1 500 500 0 Feb 12 14:33 mounts lrwxrwxrwx 1 500 500 0 Feb 12 14:33 root -> /mnt/build/rebuildtest -r--r--r-- 1 500 500 0 Feb 12 14:33 stat -r--r--r-- 1 500 500 0 Feb 12 14:33 statm -r--r--r-- 1 500 500 0 Feb 12 14:33 status
please "kill -8 PID" the runaway process and look at the backtrace in "gdb -c core.PID", does that help? ("ulimit -c 1000000" as well, default coredump size might be 0)
It's going to take a while to do this on the machine I saw the problem on (there's a lot happening on that machine right now), but I'm trying. Just starting the rebuild of the package is taking a very long time. If you want to reproduce this just try rebuilding the gdb-5.3post-0.20021129.11 package on a machine which is running 2.4.20-2.47.1.
do this on perf53 to reproduce the failure (as root, in the /root directory): # /tmp/attach2.1414 & [1] 14152 # gdb (gdb) attach 14152 (gdb) s should_exit=1 Program received signal SIGSTOP, Stopped (signal). sometimes a 'c' has to be done, and the bogus SIGSTOP message is displayed then. This is clearly a SIGCONT/SIGSTOP or ptrace bogosity.
I did already create a gdb bug for this. 84220. I disabled the tests in the gdb-5.3post-0.20021129.12 build, so this shouldn't affect you guys any more. It is gdb's fault that it doesn't clean after itself if something goes wrong during the test. The reason that this didn't happen with older kernels (pre NPTL) is that now there is an extra SIGSTOP after attaching to a process, and gdb doesn't handle that properly. This screws up the whole test sequence. So I am going to close this. OK?
*** This bug has been marked as a duplicate of 84220 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.