Re: linux-nat.c:471: internal-error: unknown ptrace event 5

[Daniel Jacobowitz <drow@false.org>]

On Mon, May 30, 2005 at 05:14:25PM +0200, Andreas Schwab wrote:
> Why is linux_handle_extended_wait not prepared to handle
> PTRACE_EVENT_VFORK_DONE?

Because it should absolutely never, ever receive it. 
PTRACE_EVENT_VFORK should be reported, then the next time we resume
child_follow_fork should be called, and that should consume the
PTRACE_EVENT_VFORK_DONE.

You didn't say what version of GDB you're using.  There've been some
changes lately.

> LLW: waitpid 8077 received Trace/breakpoint trap (stopped)
> LLW: Handling extended status 0x02057f
> LLTA: PTRACE_PEEKUSER LWP 8077, 0, 0 (OK)
> LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 8077.
> SC:  kill LWP 8522 **<SIGSTOP>**
> SC:  lwp kill 0 ERRNO-OK

...

> WL: waitpid LWP 8071 received Stopped (signal) (stopped)
> LLW: trap_ptid is LWP 8077.
> Attaching after fork to child process 8547.
> RC:  PTRACE_CONT LWP 8522, 0, 0 (resume sibling)

...

> LLR: PTRACE_CONT process 8547, 0 (resume event thread)
> LLW: waitpid 8077 received Trace/breakpoint trap (stopped)
> LLW: Handling extended status 0x05057f
> linux-nat.c:471: internal-error: unknown ptrace event 5

It looks like you're using 'set follow child'.  Is that right?  If so,
it looks like I never extensively tested the child-side path using
multiple threads; that would make sense, since when I wrote it NPTL was
very new, and LinuxThreads doesn't use vfork with threads.  It will
need a bit of work; the problem is that we are bypassing target_detach
for the vfork, but we really do want to detach.  Just not yet.

-- 
Daniel Jacobowitz
CodeSourcery, LLC