From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4249 invoked by alias); 22 Mar 2004 20:20:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4198 invoked from network); 22 Mar 2004 20:20:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Mar 2004 20:20:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B5Vub-0004ts-Q8; Mon, 22 Mar 2004 15:20:41 -0500 Date: Mon, 22 Mar 2004 20:20:00 -0000 From: Daniel Jacobowitz To: Michael Snyder , gdb-patches@sources.redhat.com Subject: [patch] Fix threads vs. fork following Message-ID: <20040322202041.GA18765@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com References: <404FBC18.4090909@redhat.com> <20040322171217.GA23193@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040322171217.GA23193@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00506.txt.bz2 On Mon, Mar 22, 2004 at 12:12:18PM -0500, Daniel Jacobowitz wrote: > On Thu, Mar 11, 2004 at 01:08:40AM +0000, Michael Snyder wrote: > > Hey Daniel, > > > > Got a question concerning the code in > > linux-nat.c::linux_handle_extended_wait. > > > > You've got a PTRACE_EVENT_FORK event, and now you're going to call > > waitpid. You pull a pid out of a list of stopped pids, and wait for > > it using waitpid. In your comment, you explain that you don't have to > > worry about the pid being a clone, because you didn't ask for pids in > > the event mask. > > > > But how is this affected by threads, especially NPTL threads? > > I've got a fairly simple test-case (modified from pthreads.c, > > I'll attach it), in which a child thread calls fork -- but gdb > > apparently tries to wait on the main thread (or perhaps the most > > recent event thread). Since that's not the thread that called > > fork, waitpid returns -1 with "no child". Gdb reports: > > waiting for new child: No child processes. > > > > FWIW, I've tried this on both a single-processor and an SMP machine. Here's what happened: I was using ptid_get_pid, which gave me the _process_ ID rather than the _lwp_ ID. I've committed this fix for HEAD. Should I fix this on the 6.1 branch also? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2004-03-22 Daniel Jacobowitz * lin-lwp.c (lin_lwp_wait): Pass the LWP ID to linux_handle_extended_wait. Index: lin-lwp.c =================================================================== RCS file: /cvs/src/src/gdb/lin-lwp.c,v retrieving revision 1.52 diff -u -p -r1.52 lin-lwp.c --- lin-lwp.c 8 Oct 2003 20:05:56 -0000 1.52 +++ lin-lwp.c 22 Mar 2004 20:02:30 -0000 @@ -1591,8 +1591,7 @@ retry: /* Handle GNU/Linux's extended waitstatus for trace events. */ if (WIFSTOPPED (status) && WSTOPSIG (status) == SIGTRAP && status >> 16 != 0) { - linux_handle_extended_wait (ptid_get_pid (trap_ptid), - status, ourstatus); + linux_handle_extended_wait (GET_LWP (lp->ptid), status, ourstatus); return trap_ptid; }