From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23103 invoked by alias); 11 Mar 2004 01:08:51 -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 23094 invoked from network); 11 Mar 2004 01:08:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Mar 2004 01:08:50 -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 i2B18n07006160 for ; Wed, 10 Mar 2004 20:08:49 -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 i2B18hM25016; Wed, 10 Mar 2004 20:08:44 -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 i2B18gR30774; Wed, 10 Mar 2004 17:08:43 -0800 Message-ID: <404FBC18.4090909@redhat.com> Date: Thu, 11 Mar 2004 01:08: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 , gdb-patches@sources.redhat.com Subject: Daniel, thread vs. fork question. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: -4.9 X-SW-Source: 2004-03.o/txt/msg00259.txt 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. Michael From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23103 invoked by alias); 11 Mar 2004 01:08:51 -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 23094 invoked from network); 11 Mar 2004 01:08:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Mar 2004 01:08:50 -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 i2B18n07006160 for ; Wed, 10 Mar 2004 20:08:49 -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 i2B18hM25016; Wed, 10 Mar 2004 20:08:44 -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 i2B18gR30774; Wed, 10 Mar 2004 17:08:43 -0800 Message-ID: <404FBC18.4090909@redhat.com> Date: Fri, 19 Mar 2004 00:09: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 , gdb-patches@sources.redhat.com Subject: Daniel, thread vs. fork question. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: -4.9 X-SW-Source: 2004-03/txt/msg00259.txt.bz2 Message-ID: <20040319000900.q9cWEyPSwaRB1Cj9pQv62ptmcqjovlGD3KL31dmDTfc@z> 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. Michael