[Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=16159

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 13 Nov 2013, bugdal at aerifal dot cx wrote:

> Carlos, this is yet another reason why dlopen'ing libgcc_s is simply the wrong
> thing to do, and libgcc_eh should be static-linked into libc. (The other big

Static-linking libgcc_eh into any glibc library is a bad idea because it 
complicates bootstrapping: it means glibc built with an initial bootstrap 
compiler (which was built without glibc headers available, implying full 
EH functionality is not present in libgcc) is not identical to glibc built 
with a compiler built using full shared glibc and headers.  (It's *also* a 
bad idea because new compilers can start using new DWARF unwind opcodes 
that an old copy of the unwind code won't understand, causing problems 
using new programs with old glibc.)

The answer for libpthread is for it to dlopen libgcc_s when loaded rather 
than at pthread_cancel time (or to be made to depend (DT_NEEDED) on 
libgcc_s in a way that doesn't require libgcc_s to be available when 
libpthread is built).  The answer for other cases is to disable the 
backtracing by default as discussed in bug 12189 (possibly with an 
environment variable, not available in setuid programs, that can reenable 
it - in which case glibc would dlopen libgcc_s at startup).

-- 
You are receiving this mail because:
You are on the CC list for the bug.