From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17554 invoked by alias); 1 Dec 2008 22:36:20 -0000 Received: (qmail 17544 invoked by uid 22791); 1 Dec 2008 22:36:20 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Dec 2008 22:35:45 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5B41631006; Mon, 1 Dec 2008 14:35:43 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost2.vmware.com (Postfix) with ESMTP id 4096C8E5D1; Mon, 1 Dec 2008 14:35:43 -0800 (PST) Message-ID: <49346647.5020908@vmware.com> Date: Mon, 01 Dec 2008 22:36:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , Pedro Alves , "gdb-patches@sourceware.org" Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp References: <200811201328.13651.pedro@codesourcery.com> <493433D7.7080803@vmware.com> <20081201205547.GA20007@caradoc.them.org> In-Reply-To: <20081201205547.GA20007@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00020.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Dec 01, 2008 at 10:58:31AM -0800, Michael Snyder wrote: >> I'm not sure if this change goes far enough. >> If a multi-threaded program forks, only the currently >> executing thread survives in the child. All others are >> left behind (and its not unlikely that the thread library >> is left in an inconsistant state, possibly leading to >> deadlocks). > > If you use fork () rather than syscall (SYS_fork), the thread library > ought to clean up first; this is a POSIX supported functionality, I > believe. I know it works with glibc and on Solaris. Of course, > Solaris has rfork too which copies threads... > All right, but separate from that, shouldn't gdb clean up too? At least do a prune-threads?