threads/76690: fork hang in child for (-lc_r & -lthr)

Sven Berkvens-Matthijsse sven at
Mon Oct 24 07:45:35 PDT 2005

> WRT to malloc() and free() within libc_r, it is always single
> threaded from the library's perspective because no other threads can
> be active at the time of the fork (libc_r is all userspace threads).

Correct. It also takes care to disable the signal handler that may
cause a thread switch in the "thread kernel".

> Probably all that needs to be done is take the malloc lock before
> forking and release it afterwards (like libpthread).

That's possible (and indeed what I do). I decided to lock the other
locks as well because programs (buggy or not) may call those library
functions after the fork (in the child) as well. We can remove those
locks if you wish, none of the functions involved are async-signal-safe,
and programs shouldn't be using them after a fork() in a threaded

> It may even be enough just to set __isthreaded to 0 in the child
> after the fork() before calling any malloc()'s and free()'s so they
> don't try to use the lock.

But then the free() in the child process may be using an unstable
state of the malloc system (because if you don't acquire the lock
before the fork(), malloc() may be busy in the middle of the fork()).

> If __isthreaded is 0 in the child, I don't think any part of libc
> will attempt to use locking.

That's correct.

> If the child tries to create any threads, then bad things may
> happen, but that's the application's fault.


> -- 
> DE


More information about the freebsd-threads mailing list