This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/4737] fork is not async-signal-safe
- From: "tom dot honermann at oracle dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 11 Nov 2008 21:39:56 -0000
- Subject: [Bug libc/4737] fork is not async-signal-safe
- References: <20070704013541.4737.nmiell@comcast.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From tom dot honermann at oracle dot com 2008-11-11 21:39 -------
(In reply to comment #7)
> It is, as far as I can see, not a problem of the fork() implementation
> allocating memory. I believe that it's:
>
> 1) a problem of glibc's malloc() implementation registering ptmalloc_lock_all()
> for execution at fork (via thread_atfork()) while not making sure that this
> function can actually be called from a signal handler without deadlocking.
> Fork() just calls each registered function. It can not, in any way, know if
> these functions will lock up the process - that is the responsibility of whoever
> registers a the function for execution. This must be a bug in malloc/arena.c.
> This is the bug you (Nicholas) hit.
Absolutely correct. ptmalloc_lock_all, ptmalloc_unlock_all, and
ptmalloc_unlock_all2 are not async-signal-safe as is required to be called
within the context of a signal handler.
>
> 2) a problem of fork() calling _IO_list_lock() which might be locked by the main
> execution flow. This must be a bug in nptl/sysdeps/unix/sysv/linux/fork.c. This
> is the bug I hit.
>
> I think it looks like two separate bugs, which are triggered by similar
> conditions. The fix might be identical; I don't know.
These look like two separate bugs to me as well. I haven't hit the
_IO_list_lock related one myself yet, but I suspect it is only a matter of time...
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4737
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.