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: "darryl.miles at darrylmiles dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 13 Nov 2013 13:00:06 +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 #6 from Darryl Miles <darryl.miles at darrylmiles dot org> ---
This fancy backtrace stuff is nice and all but... the process must die!
Can't the pthread_once use a non-blocking lock ?
Can the lock be a recursive type ?
Can pthread_trylock() used in this non-critial path ? if already locked, and
if possible to check if locked by our thread-id ?
then we immediately abort the process (causing execution of the process to die,
like it should). No backtrace is emitted, great!
How do I stop this fancy backtrace stuff from working ? I want to setup an
environment variable to turn it off as a workaround ?
How do I make this fancy backtrace stuff work, by preloading the dlopen() stuff
it might need, during initialization of malloc() ? I want to setup an
environment variable for that too.
There is no need to actually fix the bug, you are over thinking the issue. But
this fancy stuff needs to be turned off or preloaded, before the process gets
into an undefined state (due to memory bug).
--
You are receiving this mail because:
You are on the CC list for the bug.