Re: [PATCH 0/2 v3] Demangler crash handler

[Gary Benson <gbenson@redhat.com>]

Andrew Burgess wrote:
> On 04/06/2014 2:34 PM, Gary Benson wrote:
> > Mark Kettenis wrote:
> > > I still very much agree with Pedro; this should not be necessary.
> > 
> > "Should" is the operative word here.  It *should* not be necessary
> > because the demangler *should* never crash.  But this isn't utopia.
> > The demangler is code, and code has bugs.  People make mistakes.
> > Things are valid now that may not be valid in the future.  And GDB
> > should not just crash if some symbol in the inferior isn't handled
> > or doesn't make sense or whatever.
> 

> By this logic should / would we not extend the SIGSEGV handler to
> cover all gdb code?

I'm not suggesting this.

> I'm just not sure why the demangler should get special treatment.

It's a combination of the severity of the impact (bugs cause GDB to
dump core on startup, with no reasonable workaround) and the fact that
the demangler is unusually recoverable (it allocates no heap, uses no
resources, and has no global state: you can peel back the stack and
carry on*).  A lesser issue is that bugs are easily reproducible when
you have the offending symbol.  I see no reason why users should be
inconvenienced (by not being able to use GDB) and why developers
should do extra work (digging symbols out of core dumps) when a
small piece of code can mitigate the impact on the user and do the
legwork for the developer, all without losing performance or consuming
resources. 

Thanks,
Gary

--
* I'm aware that memory can be corrupted before the segmentation
fault is triggered, meaning GDB *might* subsequently crash.  My
position is that "might crash later" is better than "definitely
crashing now".