Bug 71166 - strace -p pid suspends pid when strace exits
Summary: strace -p pid suspends pid when strace exits
Status: CLOSED DUPLICATE of bug 64303
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: strace
Version: limbo
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
: 84954 (view as bug list)
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
Reported: 2002-08-09 15:04 UTC by Jay Berkenbilt
Modified: 2007-04-18 16:45 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2002-08-10 20:38:37 UTC

Attachments (Terms of Use)

Description Jay Berkenbilt 2002-08-09 15:04:42 UTC
Description of Problem:

When you run strace -p on a process and then interrupt strace, the traced
process ends up suspended after strace exits.  This is somewhat similar to the
problem reported in bug 63370, but much simpler and slightly different, so I've
decided to open a new bug rather than have that complex one kicking around for a
tiny aspect of the original problem.  This problem exists in Limbo and also in

Version-Release number of selected component (if applicable):

strace-4.4-4, kernel 2.4.18-3, -5 (Valhalla)
strace-4.4-6, kernel 2.4.18-7.80 (Limbo)

How Reproducible:


Steps to Reproduce:
1. /bin/sleep 10 &
2. strace -p $!

Actual Results:

strace exits, the sleep process suspends

Expected Results:

the traced process should not be left suspended

Additional Information:

This does not depend upon the fact that the sleep process is in system call when
strace exits.  You can do the same experiment with the following C program:

int main() { while (1) {} }

which clearly doesn't call any system calls once it starts.  If you start this
in the background and then strace it and exit strace, it too stops.  It also
doesn't have anything to do with controlling ttys or job control -- you can
start this is (./a.out < /dev/null > /dev/null 2>&1 &) and then strace -p its
pid from another shell.  The same thing happens.

This is most disconcerting when done on a system process.  Unlike in some
previous situations, kill -CONT does restore everything to normal, but one
doesn't expect strace to leave things in a suspended state.  I'm marking this as
severity "high" because there is no known workaround.  I don't have any idea 
what the fix is, though I suppose it may work to have the strace process
explicitly send a CONT signal to the process after releasing it.  This would, of
course, just be a workaround and not a correct fix....   I don't know whether
this is an strace issue or a kernel issue.  I haven't experimented with 
multithreaded programs with respect to this problem.

Comment 1 Roland McGrath 2002-08-20 23:06:27 UTC

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

Comment 2 Roland McGrath 2003-02-24 21:14:39 UTC
*** Bug 84954 has been marked as a duplicate of this bug. ***

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