[Bug 2341] Forked new process with locked malloc mutex

bugzilla at busybox.net bugzilla at busybox.net
Fri Dec 3 21:03:15 UTC 2010


https://bugs.busybox.net/show_bug.cgi?id=2341

--- Comment #2 from Robin Haberkorn <rh at travelping.com>  ---
Created attachment 2767
  --> https://bugs.busybox.net/attachment.cgi?id=2767
patch to apply in addition to the malloc-fork patch to resolve setenv()
'deadlocks'

patch for setenv()/fork() in a similar spirit as patch 2293 (based on another
uclibc git checkout, though). this is only a quick fix and might not be
completely correct.

I'd like to raise another point: can this be considered a bug at all?
glibc's malloc implementation makes malloc() safe after forking using atfork
handlers but POSIX.1-2001 states that for the very reason causing these
'deadlocks', you should only use async-signal-safe functions (they are
guaranteed not to use any threading primitives) after forking but before exec()
in the child process, at least in multi-threaded environments.

see: http://www.opengroup.org/onlinepubs/000095399/functions/fork.html

so am I missing some specification uClibc wants to support but stating that
this has to work or is it just a nice-to-have glibc-compatibility feature?

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the uClibc-cvs mailing list