From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19996 invoked by alias); 9 Mar 2004 02:53:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19968 invoked from network); 9 Mar 2004 02:53:00 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Mar 2004 02:53:00 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0XMV-00037C-3T; Mon, 08 Mar 2004 21:52:55 -0500 Date: Tue, 09 Mar 2004 02:53:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Ulrich Weigand , gdb@sources.redhat.com Subject: Re: getpid after vfork broken in recent glibc Message-ID: <20040309025255.GA11922@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Ulrich Weigand , gdb@sources.redhat.com References: <404D2EB9.10607@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404D2EB9.10607@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00060.txt.bz2 On Mon, Mar 08, 2004 at 09:40:57PM -0500, Andrew Cagney wrote: > >Hello, > > > >in fork_inferior (fork-child.c), gdb uses vfork () to spawn a child > >process, and then calls getpid () (within gdb_setpgid) from within > >that child process, before doing the execve (). > > > >With current glibc CVS builds, this doesn't work any more, since > >glibc caches the PID in thread-local memory, and memory is shared > >between vfork parent and child. (In fact, what happens is that > >all subsequent getpid calls in gdb return the pid of the initial > >child that was spawned ...) This causes various breakage. > > > >Now, according to this libc-hacker thread: > >http://sources.redhat.com/ml/libc-hacker/2004-03/msg00014.html > >gdb's behaviour is actually not standards-compliant, as it is not > >permitted to call getpid () between the vfork and the exec. > > > >Can this be fixed in gdb? > > We might as well simply always use fork -- the "performance" benefit is > hardly valid any more (Hmm, perhaps something related to this is why > vfork never worked, and hence was disabled, on HP/UX). Since I went to some trouble to make "shell escape" use vfork when possible (2003-06-21), I have to disagree with your assumption. When GDB is using a good-sized chunk of the RAM on a system, forking unnecessarily is a real pain. Given the idiotic definition of vfork, though, I guess we don't have a choice. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer