Re: [patch] Fix attaching to Linux stopped processes

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Sat, 23 Sep 2006 19:36:37 +0200, Mark Kettenis wrote:
...
> > Also the patch looks right to me - after `PT_ATTACH' it is appropriate that
> > `WSTOPSIG (status)' will report the original signal that stopped process,
> > (WSTOPSIG (status) == SIGSTOP) <=> (process was in running/sleeping mode).
> 
> Whoa stop, the status returned by wait(2) doesn't tell you whether a
> process is sleeping or running.  Traditionally, after invoking
> ptrace(PT_ATTACH, ...) the kernel will always respond with a SIGSTOP.
> Any information about any previous signals is lost.

(Red Hat) kernel 2.6.17-1.2647.fc6 reports SIGSTOP for running processes and
0 for processes already stopped before ptrace(PTRACE_ATTACH).  It does not
differentiate SIGTTIN vs. SIGSTOP etc., though, as I expected, thanks.

I found in POSIX that the waitpid(2) vs. ptrace(2) behavior is underfined:
	http://www.opengroup.org/onlinepubs/009695399/functions/wait.html
	Since ptrace() is not part of this volume of IEEE Std 1003.1-2001,
	[ I did not find any other ptrace(2) on http://www.opengroup.org/ . ]


> This all smells like a race condition in the kernel to me.  The
> linux-nat.c code is quite hairy already.  I'd suggest fixing the
> kernel rather than adding more workarounds.

Do you have some standard/specification to follow?
I found more that the WSTOPSIG() _should_ report the specific signal:
	http://www.scit.wlv.ac.uk/cgi-bin/mansec?3B+wait4
	the 8 bits higher up from the low-order 8 bits of w_status contain the
	number of the signal that caused the process to stop.
	See ptrace(2) and sigvec(3UCB).


Regards,
Jan