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
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 17 Sep 2006 18:26:22 -0400
- Subject: Re: [patch] Fix attaching to Linux stopped processes
- References: <20060917221228.GA17263@host0.dyn.jankratochvil.net>
On Mon, Sep 18, 2006 at 12:12:28AM +0200, Jan Kratochvil wrote:
> Hi,
>
> sleep 1h& pid=$!; kill -STOP $pid; gdb sleep $pid
> ->
> Attaching to program: /bin/sleep, process 20768
> ../../gdb/linux-nat.c:1057: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed.
> + /* Do not check `WSTOPSIG (status) == SIGSTOP' as the status may be
> + arbitrary - depending on the signal that stopped the processes.
> + If the process was running we get SIGSTOP, if it was already stopped
> + by SIGSTOP we get 0. The value gets used for `PTRACE_CONT'. */
That's a very strange behavior. It doesn't make much sense to me, and
it isn't familiar - which is strange because I've been all over the
kernel code for this. 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?
--
Daniel Jacobowitz
CodeSourcery