[uClibc] vfork() wrapper in libpthread: BAD!

Alexandre Oliva aoliva at redhat.com
Mon May 3 23:22:21 UTC 2004


Hi,

The vfork() wrapper defined in libpthread, that's used to run
pthread_atfork()-registered handlers, is not only a very bad idea,
it's broken and useless.  Here's the rationale:

The function that calls vfork() (even if it's called __libc_vfork())
must never return in the child, otherwise it corrupts the stack frame
and, when the parent attempts to return, it gets in trouble.

The function that calls vfork() must not do anything significant
before calling one of the functions of the exec() family, or _exit().

The point of pthread_atfork() is to enable a multi-threaded fork()ed
application to arrange for any variables that would have been left at
an inconsistent state in the child to be fixed up for continued
execution of both parent and child as separate processes.

With vfork(), this simply doesn't make sense.  The only useful thing
the child can do is to exec() some program or _exit(), both of which
remove any state shared.

Running pthread_atfork() child and parent handlers can actually be
harmful, since these handlers are meant to be run after the states of
the parent and child have been cloned and started to diverge.  With
vfork(), this doesn't happen: it's the same state, so a correct use of
pthread_atfork() could end up leaving the parent with a corrupted
state.


Since the implementation as it stands is broken (linking a program
that vfork()s and exec()s on the child and wait()s on the parent works
unless you happen to link with libpthread), and I can't think of
any workable solution, I suggest that we simply remove the vfork()
overrider in the non-MMU case.  Yes, we might lose some small amount
of functionality here, but it's not like people running uClinux expect
anything resembling actual fork() to work.

Comments?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



More information about the uClibc mailing list