Re: [PATCH 0/2] Demangler crash handler

[Gary Benson <gbenson at redhat dot com>]

Pedro Alves wrote:
> On 05/14/2014 05:08 PM, Andrew Burgess wrote:
> > On 14/05/2014 3:01 PM, Pedro Alves wrote:
> > > 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.
> 
> Well, that's fine, and I think that it's a matter that can be
> changed independently of the scheme used to detect bad state
> in the demangled.  For instance, we can have GDB's
> demangler_internal_error callback throw a normal error, and
> then catch it from within gdb_demangle, and have that return
> NULL.

The demangler already has a system in place to handle early
termination.  It's not gdb_demangle that needs to return NULL:
it's the demangler's API to return NULL if the symbol cannot be
demangled.

It's not clear to me what benefit a second system for early
termination would add, or how you would decide which system
to use for any given error.

> ...the idea is about protecting against really bad state, not
> unimplemented features.

The thing is, everything's fine once you've *detected* the bad
state: you can handle it however you want.  Which, using the
demangler's current convention, is either "handle the state" or
"d_print_error (&dpi); return;".  The whole point of the segfault
catcher was to cope with undetected bad state.

I'm not saying we should not try and fix more places where bad
state is undetected.  My point was that no matter how much work
you put in you still can never say "ok, we got all the bugs now".
That's what the segfault catcher was for.

> We should really prevent that with better testing, e.g., the
> demangle-the-world testing, and/or fuzzy testing.

Agreed.  If nothing else comes out of this discussion but more
testing then it's all been worthwhile.

Thanks,
Gary

-- 
http://gbenson.net/