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
Valhalla.

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:

always


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

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.