RE: Patch: FYI: PR 7570 and PR 7578

["Boehm, Hans" <hans_boehm at hp dot com>]

The problem only applies to threaded programs.  The issue is that fork() only duplicates a single thread in the child.  Thus the child looks like a copy of the parent in which all threads but one suddently died, but locks held by the other threads are still held.  Thus a malloc in the child can fail if another thread in the parent happened to hold the malloc lock at the time of the fork.

I have no idea whether glibc guards against this by acquiring malloc etc. locks before the fork and releasing them just after.  (See pthread_atfork() for a hook to do this.)  But the standards don't require it, at least by my reading.

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Wednesday, August 14, 2002 10:41 AM
> To: Andrew Pinski
> Cc: Java Patch List
> Subject: Re: Patch: FYI: PR 7570 and PR 7578
> 
> 
> >>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:
> 
> Andrew> There was a second patch which fix the problem that 
> allocate the c
> Andrew> string
> Andrew> for the directory before forking could you try that 
> one may be use that
> Andrew> one instead of the one you applied.  I think this is 
> a problem because
> Andrew> (according to posix)
> Andrew> Consequently, to avoid errors, the child process may 
> only execute
> Andrew> async-signal-safe operations until such time as one 
> of the exec
> Andrew> functions is called, I think memory allocating is not
> Andrew> async-signal-safe.
> 
> Part of your message is missing.  Is this a limitation only on
> threaded programs?  Does it really refer to fork() and not vfork()?  I
> find that surprising, but then I don't really keep up with POSIX :-(.
> Could you explain the problem in more depth for me?
> 
> Tom
>