* Re: getpid after vfork broken in recent glibc
@ 2004-03-09 18:53 Ulrich Weigand
0 siblings, 0 replies; 6+ messages in thread
From: Ulrich Weigand @ 2004-03-09 18:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Eli Zaretskii, Daniel Jacobowitz, cagney, gdb
Andreas Schwab wrote:
>Eli Zaretskii <eliz@elta.co.il> writes:
>
>> How about if glibc did us a small favor and invalidated its cached
>> PID on a vfork?
>
>This is about to be fixed now.
OK, thanks. I'll ask Martin to provide the s390 pieces ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* getpid after vfork broken in recent glibc
@ 2004-03-08 19:17 Ulrich Weigand
2004-03-09 2:41 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Weigand @ 2004-03-08 19:17 UTC (permalink / raw)
To: gdb
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?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getpid after vfork broken in recent glibc
2004-03-08 19:17 Ulrich Weigand
@ 2004-03-09 2:41 ` Andrew Cagney
2004-03-09 2:53 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2004-03-09 2:41 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb
> 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).
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getpid after vfork broken in recent glibc
2004-03-09 2:41 ` Andrew Cagney
@ 2004-03-09 2:53 ` Daniel Jacobowitz
2004-03-09 6:36 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-03-09 2:53 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ulrich Weigand, gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getpid after vfork broken in recent glibc
2004-03-09 2:53 ` Daniel Jacobowitz
@ 2004-03-09 6:36 ` Eli Zaretskii
2004-03-09 13:14 ` Andreas Schwab
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2004-03-09 6:36 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: cagney, Ulrich.Weigand, gdb
> Date: Mon, 8 Mar 2004 21:52:55 -0500
> From: Daniel Jacobowitz <drow@false.org>
> >
> > 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.
How about if glibc did us a small favor and invalidated its cached
PID on a vfork?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getpid after vfork broken in recent glibc
2004-03-09 6:36 ` Eli Zaretskii
@ 2004-03-09 13:14 ` Andreas Schwab
0 siblings, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2004-03-09 13:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Daniel Jacobowitz, cagney, Ulrich.Weigand, gdb
Eli Zaretskii <eliz@elta.co.il> writes:
> How about if glibc did us a small favor and invalidated its cached
> PID on a vfork?
This is about to be fixed now.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-03-09 18:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-09 18:53 getpid after vfork broken in recent glibc Ulrich Weigand
-- strict thread matches above, loose matches on Subject: below --
2004-03-08 19:17 Ulrich Weigand
2004-03-09 2:41 ` Andrew Cagney
2004-03-09 2:53 ` Daniel Jacobowitz
2004-03-09 6:36 ` Eli Zaretskii
2004-03-09 13:14 ` Andreas Schwab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox