This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: getpid after vfork broken in recent glibc
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, gdb at sources dot redhat dot com
- Date: Mon, 8 Mar 2004 21:52:55 -0500
- Subject: Re: getpid after vfork broken in recent glibc
- References: <OF1553E6EB.11E0F0CB-ONC1256E51.0068BC37@de.ibm.com> <404D2EB9.10607@gnu.org>
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