This is the mail archive of the
mailing list for the glibc project.
Re: malloc->backtrace->dlopen->malloc deadlock
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Tue, 12 Jan 2016 20:10:15 -0500
- Subject: Re: malloc->backtrace->dlopen->malloc deadlock
- Authentication-results: sourceware.org; auth=none
- References: <20160108233734 dot 1E2262C3C70 at topped-with-meat dot com> <20160109042506 dot GD30273 at devel dot intra dot reserved-bit dot com> <20160112210114 dot C40C92C3C43 at topped-with-meat dot com>
On 01/12/2016 04:01 PM, Roland McGrath wrote:
>> Based on the backtrace in the bz, this looks like a different (and
>> new) problem from #16159. The deadlock seems to be happening on the
>> mtrace-internal LOCK and not the arena lock. We never attempted to
>> fix that with #16159; our fix was limited to making malloc itself work
>> and we never got to any use cases beyond that.
> Carlos had previously raised a question about user-supplied malloc
> implementations calling dlopen. That might be the case that seemed most
> related to 16573. But I don't recall if there was a resolution to that.
The bug is in mtrace, and is exactly as the submitter describes.
Foreign function hooks left in place when real malloc is called must be SR-safe .
The foreign function hooks implemented by malloc/mtrace.c are not SR-safe
and therefore are prone to deadlock on their own locks.
One way to fix this is to remove all foreign function hooks when calling the
real malloc (as submitter suggets, which is a good short-term solution).
The other way is to rewrite the foreign functions to be SR-safe and tolerate
being called again.
To answer your last question "Is it valid for a user-supplied malloc to call
dlopen?" The answer is "No." The community agreed that no blanket statement
should be made about the SR-safety of any group of functions and that each
function should be evaluated and documented. As of today a user-supplied malloc
may only make AS-safe function calls to avoid potentially calling a library
routine reetrantly that cannot handle such an invocation. And none of this is
formally documented yet.