This is the mail archive of the
mailing list for the glibc project.
Re: RFC: Deadlock in multithreaded application when doing IO and fork.
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>
- Date: Thu, 14 Apr 2016 10:11:25 +0200
- Subject: Re: RFC: Deadlock in multithreaded application when doing IO and fork.
- Authentication-results: sourceware.org; auth=none
- References: <510AF80E dot 5020400 at redhat dot com>
On 02/01/2013 12:02 AM, Carlos O'Donell wrote:
another thread could be inside malloc and trigger an
assertion or debug output, which will block, and
deadlock fork() e.g.
takes arena lock.
malloc aborts and tries to do IO.
user define malloc tries to do IO.
blocks on list_all_lock.
blocks on arena lock
The bug discussed in this old thread is now fixed on master, with commit
IMO, the deadlock you describe is not relevant because list_all_lock is
only taken on fflush (NULL) or if a stdio stream is opened or closed.
abort does not flush the streams under list_all_lock (ugh). Opening or
closing a stdio stream performs malloc or free, so it will potentially
deadlock even without the presence of list_all_lock, just involving the
malloc locks. A malloc calling into stdio is just undefined. We get
away with it to some extent because we implement both, but an interposed
malloc cannot do this.