Re: [PATCH] Avoid deadlock in malloc on backtrace

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Tue, Feb 24, 2015 at 09:51:57AM -0800, Paul Eggert wrote:
> On 02/24/2015 03:51 AM, Siddhesh Poyarekar wrote:
> >dynamically loading the library requires malloc
> 
> How about dynamically linking _Unwind_Backtrace etc. at startup, rather than
> doing it lazily after heap memory may been corrupted and one really needs
> the backtrace?

That seems to be off the table because it complicates bootstrapping:

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

> It is news to me that 'backtrace' can call 'malloc' the first time that one
> uses 'backtrace'.  Now that I know this, I suppose I should modify Emacs to
> do a no-op call to 'backtrace' first thing, before Emacs does anything
> important.  That way, when Emacs really needs to call 'backtrace' due to a
> bad pointer or whatever, we'll have more confidence that the call to
> 'backtrace' will actually work.
> 
> But really, we shouldn't have to modify applications to work around this
> problem, and the problem should be fixed in glibc.  'backtrace' shouldn't
> require 'malloc' to work, as we want 'backtrace' to get a backtrace as
> reliably as possible even when part of memory is corrupted.

But how useful is the backtrace anyway?  Most distributions have abrt
or equivalent to get much more useful information from crashes from
programs and that method seems much more secure since they're doing it
from a separate process context and not from within a process that has
corrupted its heap.

Siddhesh

Attachment: pgpMK1TbxFmci.pgp
Description: PGP signature