Re: [patch] Fix Linux attach to signalled/stopped processes

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Mon, 31 Mar 2008 21:18:51 +0200, Doug Evans wrote:
> Was there any final resolution on this patch?
> 
> http://sourceware.org/ml/gdb-patches/2007-06/msg00546.html
> http://sourceware.org/ml/gdb-patches/2007-07/msg00003.html
> 
> It doesn't seem to have gotten checked in but I couldn't find an
> explanation.  I don't see the problem on my fc8 box but I do see the
> problem on an older one, so I'm guessing it was resolved to leave GDB
> alone and leave the fix to the kernel.  Is that correct?

No, Fedora kernel ptrace(2)/waitpid(2) etc. syscalls (which use ptrace
emulation running on top of the utrace subsystem) behave exactly the same as
their kernel.org counterparts - except various bugs are being fixed by Roland
McGrath in both of the implementations.  The ptrace validity tests are at:
	http://sourceware.org/systemtap/wiki/utrace/tests

The signaling problem needs to be handled carefully in GDB itself as the
ptrace(2) API standard is unfriendly in these conditions:
	http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/gdb/devel/gdb-6.7-bz233852-attach-signalled-fix.patch
	http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/gdb/devel/gdb-6.7-bz233852-attach-signalled-test.patch
(it applies OK, runtime not tested without the other Fedora patches there)

Current/latest update of Fedora 8 already contains all the gdb changes (and
kernel utrace compatibility fixes with kernel.org ptrace) to be in a good
shape.  Older Fedora kernel+gdb did have various bugs in this functionality.

The GDB patch is fully compatible with the kernel.org (non-utrace) ptrace.
The patch addresses these two issues:
 * Attachment to a process which is stopped (kill -SIGSTOP).
 * Attachment to a process with a rare race condition of having a signal
   currently being delivered - WAITPID returns there the signal which needs
   to be redelivered (otherwise it gets lost), upstream GDB assertion-fails
   as it will not get the expected SIGSTOP signal (which comes on next WAITPID
   from the kernel queue).

Current patch still has one known problem that if we have a process already
stopped and we attach to it by GDB with this patch it may start with the
inferior state several instructions later than it was originally stopped.
	https://bugzilla.redhat.com/show_bug.cgi?id=244162#c17
It would be solvable if we would delay each attachment to a stopped process by
some constant delay - such as 1 second - to give it a time for landing of all
the possibly pending signals.  OTOH probably better way to solve this flaw is
to move from the ptrace(2) interface to the utrace interface (AFAIK with its
userland part not defined so far) as the patch in its current form is insane.

Also the more generic question may be what should happen if we try to attach
a debugger to a SIGSTOPped process.  Naive debugger will hang - this is right
as the inferior is stopped - it should not run any operation, incl. its
debugging.

The condition whether the detached process (previously attached as stopped)
should be left stopped or running is not intuitive there now, it is Red Hat
patches backward compatible but IMO it should rather ask the user (with
a default of leaving it stopped).

This patch was developed with a lot of ptrace(2) info from Roland McGrath.



Regards,
Jan