Bug 84222

Summary: kernel-2.4.20-2.47.1 + testsuite from gdb-5.3post-0.20021129.11 = bad juju
Product: [Retired] Red Hat Linux Reporter: Tim Powers <timp>
Component: gdbAssignee: Elena Zannoni <ezannoni>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: ezannoni, roland, sopwith
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:51:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 79578    

Description Tim Powers 2003-02-13 17:21:52 UTC
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

Comment 1 Ingo Molnar 2003-02-13 17:34:56 UTC
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)


Comment 2 Tim Powers 2003-02-13 18:41:26 UTC
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. 


Comment 3 Ingo Molnar 2003-02-13 18:51:17 UTC
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.


Comment 6 Elena Zannoni 2003-02-13 23:23:51 UTC
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?

Comment 9 Matt Wilson 2003-02-14 05:44:09 UTC

*** This bug has been marked as a duplicate of 84220 ***

Comment 10 Red Hat Bugzilla 2006-02-21 18:51:46 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.