This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
                 CC|                            |carlos at redhat dot com

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
This is going to be difficult to fix and invasive. I will do my best to explain
why.

At the point of the failure we want to be able to print a backtrace. The only
way to get a reliable backtrace is to use the unwinder provided by gcc via
libgcc_s.so.1 (this may vary by machine). In order to get access to the
unwinder we must dlopen that shared library. During the dlopen process we need
to calloc enough structures to hookup the new shared library into the
structures used by the dynamic linker.

One resolution to this problem is to ensure that malloc has a fall-back
allocation scheme that is robust against failure and then during the
malloc_printerr we flip an internal bit and switch to the temporary reserve
allocations. We could also create a new internal API for using the temporary
allocations and then dlopen could use that in the event that we are crashing
and need to dlopen one last library (the unwinder on demand). That would
prevent other threads from consuming the reserve allocations after
malloc_printerr is entered by another thread.

This is a considerable amount of work and we aren't going to get to this issue
until a core developer or someone with serious interest commits to fixing this.
Therefore I'm moving this to SUSPENDED until we find the resources to fix the
issue.

This issue should remain open and new issues submited about this bug should be
marked as duplicates of this issue.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]