This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Timing window in NPTL fork.c causes hangs.

From: Steven Munroe <munroesj at us dot ibm dot com>
To: Ulrich Drepper <drepper at redhat dot com>
Cc: GNU libc hacker <libc-hacker at sources dot redhat dot com>
Date: Mon, 26 Feb 2007 09:44:33 -0600
Subject: Re: Timing window in NPTL fork.c causes hangs.
References: <45DA0AD6.5060107@us.ibm.com> <45E203C8.50600@redhat.com>

Ulrich Drepper wrote:
> I assume this is the same issue fixed by the patch I just applied!?
>
>   
No this is a different hang. Suzuki's bug caused hangs in the child
process. This bug causes hangs (in malloc) in multithreaded parent
processes.

The NPTL implementation of fork is not atomic relative to glibc's
internal (i.e. malloc's) atfork() handling. If the forking thread takes
a signal after atfork prepare and before atfork parent processing AND
the signal handler blocks for any reason, any other thread attempting a
malloc will hang. If the forking threads signal handler is dependent in
any way on other threads to complete then we can see a deadlock.

One way to resolve this is to mask signals from before atfork prepare
until after atfork parent/child processing.

References:
- Timing window in NPTL fork.c causes hangs.
  - From: Steven Munroe
- Re: Timing window in NPTL fork.c causes hangs.
  - From: Ulrich Drepper

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]