From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9917 invoked by alias); 22 Mar 2004 17:12:22 -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 9889 invoked from network); 22 Mar 2004 17:12:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Mar 2004 17:12:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B5SyI-0001Hw-K9; Mon, 22 Mar 2004 12:12:18 -0500 Date: Mon, 22 Mar 2004 17:12:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: Daniel, thread vs. fork question. Message-ID: <20040322171217.GA23193@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com References: <404FBC18.4090909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404FBC18.4090909@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00497.txt.bz2 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. Actually, what happens is GDB tries to wait on pid 0. Here's why: errno = 0; ret = ptrace (PTRACE_GETEVENTMSG, pid, 0, &new_pid); printf ("getevent: ret %d, errno %d, new_pid %d\n", ret, errno, new_pid); getevent: ret 0, errno 0, new_pid 0 waiting for new child: No child processes. So PTRACE_GETEVENTMSG did not return the correct message. I can't see why it doesn't. My guess is that I overlooked something big in the kernel-side implementation but I'm going to have to go digging to figure out what it is. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer