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:14:01 -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> <5695A3F7 dot 3030301 at redhat dot com>
On 01/12/2016 08:10 PM, Carlos O'Donell wrote:
> 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.
To be clear, my intent is to mark quite a large amount of the library SR-safe,
and to ensure user-supplied malloc's work without the punitive requirement of
using only AS-safe functions. This is still a long term plan.