The following reply was made to PR gdb/2054; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@xxxxxxxxx>
To: Adam Jackson <ajackson@xxxxxxxxxx>
Cc: gdb-gnats@xxxxxxxxxxxxxxxxxx
Subject: Re: gdb/2054: can't start X server under gdb
Date: Wed, 4 Jan 2006 11:46:09 -0500
On Wed, Jan 04, 2006 at 11:28:24AM -0500, Adam Jackson wrote:
>
> On Dec 20, 2005, at 11:34 AM, Daniel Jacobowitz wrote:
> >
> >Oh sorry - you have to not use strace -f with gdb, because only one
> >process can ptrace a target at a time. We want a trace of GDB, but not
> >of the X server.
>
> Right, forgot about that bit. Updated trace is at:
>
> http://people.freedesktop.org/~ajax/gdb-bug-2054/strace-of-gdb-2.txt
So here's what happened - your strace unfortunately doesn't show some
details, but I can guess them pretty confidently:
ptrace(PTRACE_CONT, 31602, 0, SIG_0) = 0
waitpid(-1, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP], 0) = 31602
We continue the parent, and it stops. At this point it is reporting a
fork.
ptrace(0x4201 /* PTRACE_??? */, 31602, 0, 0xbff15d38) = 0
We fatch the PID of the forked child.
waitpid(31661, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP], 0) = 31661
We wait for the forked child to stop. Waitasec! It didn't stop! Not
only didn't it stop, it reported an EXEC event (which we did request,
contrary to what I said earlier in this bug report).
So we should have seen a SIGSTOP from the newly forked child, but
didn't.
The code that is supposed to guarantee this is in kernel/fork.c, and
seems to be intact in the latest kernel that I checked. I'm stumped.
Might want to make sure that's triggering. Or, when GDB prints the
error message, check /proc for the child process - does it have a
pending SIGSTOP still?
--
Daniel Jacobowitz
CodeSourcery
|
