From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1404 invoked by alias); 30 May 2005 17:05:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1355 invoked by uid 22791); 30 May 2005 17:04:58 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 30 May 2005 17:04:58 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DcnhA-0006J3-Fk; Mon, 30 May 2005 13:04:56 -0400 Date: Mon, 30 May 2005 17:05:00 -0000 From: Daniel Jacobowitz To: Andreas Schwab Cc: gdb@sources.redhat.com, Indraneel Sarkar Subject: Re: linux-nat.c:471: internal-error: unknown ptrace event 5 Message-ID: <20050530170456.GB24005@nevyn.them.org> Mail-Followup-To: Andreas Schwab , gdb@sources.redhat.com, Indraneel Sarkar References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00368.txt.bz2 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 **** > 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