From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23808 invoked by alias); 23 Mar 2004 20:17:32 -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 23793 invoked from network); 23 Mar 2004 20:17:30 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 Mar 2004 20:17:30 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2NKHTWA032621 for ; Tue, 23 Mar 2004 15:17:29 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2NKHSM14066; Tue, 23 Mar 2004 15:17:28 -0500 Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i2NKHRC07753; Tue, 23 Mar 2004 12:17:28 -0800 Message-ID: <40609B57.500@redhat.com> Date: Tue, 23 Mar 2004 20:17:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030922 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [patch] Fix threads vs. fork following References: <404FBC18.4090909@redhat.com> <20040322171217.GA23193@nevyn.them.org> <20040322202041.GA18765@nevyn.them.org> In-Reply-To: <20040322202041.GA18765@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: 0 X-SW-Source: 2004-03/txt/msg00531.txt.bz2 Daniel Jacobowitz wrote: > 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? > I don't see why not. FYI, I've had feedback from one user who says this patch helped get him past the point at which he was stuck before -- but he's seeing a new problem which may or may not be related. He has one thread which calls system("/bin/ls"), and system ("cd <...>"). He can now get past at least the first few such calls under GDB, but eventually (and non-deterministically), he sees something like: Detaching after fork from child process 22087. ---Type to continue, or q to quit--- And then for some unknown percent of the times when the above occurs, it goes more like this: Detaching after fork from child process 21502. Suspended (tty output) [msnyder@reddwarf gdb]$ fg /export/msnyder/03r1-2/bin/gdb ... ---Type to continue, or q to quit--- Detaching after fork from child process 21510. Any thoughts?