This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Avoid deadlock in malloc on backtrace
- From: Florian Weimer <fweimer at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Tue, 24 Feb 2015 12:55:59 +0100
- Subject: Re: [PATCH] Avoid deadlock in malloc on backtrace
- Authentication-results: sourceware.org; auth=none
- References: <20150224100249 dot GA31871 at spoyarek dot pnq dot redhat dot com> <54EC52E6 dot 5010905 at redhat dot com> <20150224115158 dot GH23807 at spoyarek dot pnq dot redhat dot com>
On 02/24/2015 12:51 PM, Siddhesh Poyarekar wrote:
> Agreed, but that would be beyond the scope of glibc. The other
> alternative would be to remove the option completely, but I don't
> know if that would be a popular choice. the backtrace and map dump
> is informative, but I don't know how many developers actually
> understand it. Even if we keep it as a non-default option, we'll
> have to fix the deadlock and the stack overflow.
I think we should really consider removal. Most distributions will
have core dump catchers once they start using a glibc version derived
Another issue in one of the glibc crash handlers is the user of
getenv, which will not work if a stack overflow has overwritten the
>> Maybe from a functionality point of view, this is the right thing
>> to do.
>> The test case is invalid for multiple reasons: the compiler can
>> detect that the pointer arithmetic before the allocated buffer is
>> invalid. There is a use-after-free. Maybe it's possible to fix
>> this with -ffreestanding; I don't know if the glibc headers obey
>> that, though.
> This is intentional to induce a memory corruption that results in
> the deadlock.
I get that, I was suggesting a way to future-proof the test case
against compiler changes.
Florian Weimer / Red Hat Product Security