This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 13 Nov 2013 16:03:05 +0000
- Subject: [Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again
- Auto-submitted: auto-generated
- References: <bug-16159-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16159
--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #9)
> 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 reason is the possibility of pthread_cancel aborting the program.)
> At one time in the distant past, it was necessary for there to only be one
> copy of this code (and its data) in the whole program; otherwise, exception
> propagation (or backtracing) across DSOs would not work reliably. But modern
> unwinding code uses dl_iterate_phdr and works fine even if multiple copies
> of the code are present in the program.
>
> Fixing this error in the way I describe will greatly simplify glibc and
> improve its reliability.
That sounds like a good idea to me, I also agree that dlopening libgcc_s.so.1
always seemed like a terrible idea to me. We just need the resources to do the
rewrite and fixup the linking to use libgcc_eh. I will leave this SUSPENDED
until we find someone to clean this up.
--
You are receiving this mail because:
You are on the CC list for the bug.