["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