[PATCH 0/2] Demangler crash handler

[Doug Evans]

On Sat, May 10, 2014 at 1:55 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Mark Kettenis:
>
>> No.  It's this skind of duct-tape that will make sure that bugs in the
>> demangler won't get fixed.  Apart from removing the incentive to fix
>> the bugs, these SIGSEGV signal handlers make actually fixing the bugs
>> harder as you won't have core dumps.
>
> I find this approach extremely odd as well.
>
>> Besides, any signal handler that does more than just setting a flag is
>> probably broken.  Did you verify that you only call async-signal-safe
>> functions in the signal handler code path?
>
> At least it doesn't make things much worse because the program is
> already in a funny state when the signal is generated.
>
> It would be more reliable to run the demangler in a separate process.

gdb can demangle a lot of symbols.
I'd be worried about the performance.

> What's so difficult about fixing the demangler?

It's not a question of not fixing the demangler.
It's a question of improving the gdb user experience.
gdb segfaults in the middle of a debugging session ARE BAD.
gdb's just a tool for solving problems, I'd rather it be robust.

Note that gdb has for a long time given the user the option of
continuing the debugging session after an internal error, instead of
just going straight to a core dump.
Demangler segv handling is no different, and if people feel the
problem is sufficient to warrant taking this step (and assuming any
technical problems are solvable), I'm ok with it.
[Whether there are intractable technical problems here I will leave to
a separate thread/subthread.  Offhand I don't know.]

As for worries about demangler bugs being less often fixed ... it's
not clear to me that would be the case.
How often would we get actionable segfault reports vs reports that
specifically say "the demangler is busted, and here's the string that
triggers the problem" ?