Re: [PATCH 0/2] Demangler crash handler

[Andrew Burgess <aburgess at broadcom dot com>]

On 14/05/2014 3:01 PM, Pedro Alves wrote:
> On 05/10/2014 09:55 PM, Florian Weimer 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.
> 
> I have to admit I'm not super keen on using signals for this either.
> For one, not all bugs trigger segmentation faults.  Then stealing
> a signal handler always has multi-threading considerations.  E.g.,
> gdb Python code could well spawn a thread that happens to call
> something that wants its own SIGSEGV handler...  Signal handlers
> are per-process, not per-thread.
> 
> How about we instead add a new hook to the demangler interface,
> that allows registering a callback that has the prototype of
> gdb's internal_error?

I thought that if the demangler couldn't demangle a symbol you
just got back NULL indicating no demangle was possible.

Given that, it's not clear to me where you'd want to use the error
handler, if you know something can't be demangled then you'd return
NULL, but if some feature wasn't implemented yet then surely you're
still better returning NULL than using the error handler, at least
that way the user of the demangler will continue using the mangled
version of the symbol.

I'm not arguing _for_ catching SEGV, I just think that an error handler
only helps with known bad states, the problem is that I think in all
known bad states the demangler should just return NULL, it's the
unknown bad states that are an issue here.

Thanks,
Andrew