Bug 233853 - attach will start to hang on SIGSTOPped processes
Summary: attach will start to hang on SIGSTOPped processes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdb
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jan Kratochvil
QA Contact:
URL:
Whiteboard:
Depends On: 189607 233540 243555
Blocks: 233852 245440
TreeView+ depends on / blocked
 
Reported: 2007-03-25 14:11 UTC by Jan Kratochvil
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHBA-2007-0554
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-07 18:07:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Fix the gdb-6.5-23.el5 testcase `gdb.threads/attach-into-signal'. (1.91 KB, patch)
2007-06-28 22:37 UTC, Jan Kratochvil
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0554 0 normal SHIPPED_LIVE gdb bug fix update 2007-10-30 15:13:04 UTC

Description Jan Kratochvil 2007-03-25 14:11:30 UTC
+++ This bug was initially created as a clone of Bug #233852 +++

[ Original RHEL3 source from Bug #189607 . ]

After a fix of `Bug 232837: utrace: PTRACE_ATTACH of SIGSTOPped process hangs'
to update the ptrace(2) syscall behavior back to the kernel.org one GDB will
start to hang during attaching to a SIGSTOPped process.  A prophecy of mine.

sleep 1h &
pid=$!
kill -STOP $pid
gdb sleep $pid
[WILL HANG]

Comment 1 RHEL Program Management 2007-03-25 14:25:15 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Comment 4 Andrew Cagney 2007-06-20 15:08:51 UTC
Fix available; Jan, tested by?

Comment 5 Jan Kratochvil 2007-06-21 05:14:17 UTC
There are two new testcases for it:

Running ../../../gdb/testsuite/gdb.threads/attach-into-signal.exp ...
FAIL: gdb.threads/attach-into-signal.exp: nonthreaded: attach (pass 1), pending
signal catch
PASS: gdb.threads/attach-into-signal.exp: successfully compiled posix threads
test case
Running ../../../gdb/testsuite/gdb.threads/attach-stopped.exp ...
PASS: gdb.threads/attach-stopped.exp: nonthreaded: set file, before attach1 to
stopped process (re-read)
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach1 to stopped, after
setting file
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach1 to stopped bt
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach1, exit leaves process
stopped
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach2 to stopped, after
setting file
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach2 to stopped bt
PASS: gdb.threads/attach-stopped.exp: continue (nonthreaded: attach2 continue)
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach2 stop interrupt
PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach2, exit leaves process
sleeping
PASS: gdb.threads/attach-stopped.exp: successfully compiled posix threads test
case  
PASS: gdb.threads/attach-stopped.exp: threaded: set file, before attach1 to
stopped process (re-read)
PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped, after
setting file
PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped bt
PASS: gdb.threads/attach-stopped.exp: threaded: attach1, exit leaves process stopped
PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped, after
setting file
PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt
PASS: gdb.threads/attach-stopped.exp: continue (threaded: attach2 continue)
PASS: gdb.threads/attach-stopped.exp: threaded: attach2 stop interrupt
PASS: gdb.threads/attach-stopped.exp: threaded: attach2, exit leaves process
sleeping

It makes no sense to test it on utrace kernels (FC6/F7/RHEL5.0), one needs to
test it on either upstream or RHEL-4 kernels.  It should be fixed for RHEL5.1.

The first testcase runs 100 attempts and sometimes it does not have the chance
to test redelivery of the signal if it does not catch it pending at all.
It is FAIl for now - as in the build system result above - but such cases could
be probably marked rather as UNRESOLVED.  To be fixed for the next upstream
submissions.
It was tested by hand on RHEL4.ppc that it PASSes (usually on about the 5th-20th
run).


Comment 8 Jan Kratochvil 2007-06-28 09:34:58 UTC
The current patch may occasionally detach an originally normal process as a
stopped one, investigating.


Comment 9 Jan Kratochvil 2007-06-28 22:37:11 UTC
Created attachment 158166 [details]
Fix the gdb-6.5-23.el5 testcase `gdb.threads/attach-into-signal'.

Code looks correct but the testcase was wrong.
Also the code must be tested on some RHEL-5.1 kernel, I was developing/testing
it on upstream 2.6.22-rc4-git7.x86_64.	RHEL-4.5 2.6.9-55.ELsmp.x86_64 kernel
is definitely incompatible.
Still the testcase will probably fail with (depending on the kernel version):
UNRESOLVED: gdb.threads/attach-into-signal.exp: nonthreaded: attach (pass 1),
pending signal catch
UNRESOLVED: gdb.threads/attach-into-signal.exp: threaded: attach (pass 1),
pending signal catch
It just means test unreproducibility, not a real failure.

Comment 11 Jan Kratochvil 2007-07-15 21:57:17 UTC
The current RHEL-5 patch is incompatible with RHEL-4 kernels (it races there).
But it is more conservative change since the mostly unchanged Jeff Johnston's
patch in RHEL-5.0 `gdb-6.3-attach-stop-20051011.patch'.
RHEL-4 kernels incompatible change was posted upstream before:
  http://sources.redhat.com/ml/gdb-patches/2007-07/msg00003.html


Comment 14 errata-xmlrpc 2007-11-07 18:07:42 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0554.html



Note You need to log in before you can comment on or make changes to this bug.