From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22352 invoked by alias); 7 Nov 2008 01:10:14 -0000 Received: (qmail 10101 invoked by uid 48); 7 Nov 2008 01:08:59 -0000 Date: Fri, 07 Nov 2008 01:10:00 -0000 Message-ID: <20081107010859.10094.qmail@sourceware.org> From: "morten+sources dot redhat dot com at afdelingp dot dk" To: glibc-bugs@sources.redhat.com In-Reply-To: <20070704013541.4737.nmiell@comcast.net> References: <20070704013541.4737.nmiell@comcast.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/4737] fork is not async-signal-safe X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00025.txt.bz2 ------- Additional Comments From morten+sources dot redhat dot com at afdelingp dot dk 2008-11-07 01:08 ------- 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. 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. -- 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.