["E. Jay Berkenbilt" <ejb@apexinc.com>] libc/1298: malloc()/fork() deadlock with linuxthreads
Andreas Jaeger
aj@suse.de
Wed Nov 10 00:42:00 GMT 1999
Hi,
here's an unsolved bug report. Wolfram Gloger made the following
comment (translated from German and abbreviated):
> The proposed fix to block signals in malloc hurds performance too
> much (two system calls for every malloc () -- argh!).
> But I've found the following in the SUS-fork spec:
> A process is created with a single thread. If a multi-threaded
> process calls fork(), the new process contains a replica of the
> calling thread and its entire address space, possibly including the
> states of mutexes and other resources. Consequently, to avoid
> errors, the child process may only execute async-signal safe
> operations until such time as one of the exec functions is
> called.
>
> The question remains if `the child process may only execute
> async-signal safe operations' strictly applies only to
> `multi-threaded' processes. IMHO each process that's linked against
> libpthread --- especially if it calls fork () in a signal handler
> --- has to be treated as such.
>
> Therefore we could check in the pthread_atfork() `prepare' handler
> for malloc if fork has been called from a signal handler - and in
> this case to not call ptmalloc_lock_all (). In the child process
> (and also in the parent until the signal returns) the heap would be
> corrupt - but `may only execute async-signal safe operations until
> such time as one of the exec functions is called' would apply here.
> Any comments?
Sorry, Wolfram if I mistranslated or misinterpreted your statements.
I'm repeating his question for:
Any comments?
Andreas
More information about the Libc-alpha
mailing list