This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix attaching to Linux stopped processes
> Date: Mon, 18 Sep 2006 11:53:31 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>
> > So I checked. Sure enough, on my 2.6.18-rc4
> > installation, this is _not_ what happens. Instead, the traditional
> > thing happens: wait hangs and no new event is returned.
> >
> > Is this new in kernel.org? Or is it a Red Hat kernel patch? Where
> > did it come from?
>
> Thanks for checking it.
> OK, the patch was originally for GDB on Red Hat "kernel-2.6.17-1.2647.fc6".
>
> Still it is reproducible even on both linux-2.6.17.13 and linux-2.6.18-rc4, you
> just need to "kill -CONT $pid" the inferior as gdb(1) will hang during
> attaching to it. Screenshot (sorry for graphics):
> http://www.jankratochvil.net/priv/gdb.png
> gdb is built from the current clean CVS snapshot.
>
> 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.
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.
Mark