Re: [PATCH 0/2] Demangler crash handler

[Pedro Alves <palves at redhat dot com>]

On 05/22/2014 01:56 PM, Gary Benson wrote:

> The point is to make it easier for users to file straightforward bug
> reports *with reproducers* rather than the opaque "GDB crashed at
> startup" bugs we've been getting at the moment that people (by which
> I mean Keith) have had to spend time triaging.  And, at the same time,
> for the user to have the option to attempt to continue using GDB to
> debug their program.  I realise that people may feel that the user
> *should* then fix GDB, but not everyone has the time or the ability
> or the inclination.  I don't want the workaround for this to become
> "try LLDB".

I still think you guys are blowing this way out of proportion.

I don't believe anyone here likes that GDB crashes.  But this demangler
is being turned into a scarecrow, for no good reason, IMO.  This is
not how we handle all others sorts of crashes, even for other libraries
in the tree (libbfd, libopcodes, etc.).

Here:

  https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&list_id=14858&product=gdb&query_format=advanced&short_desc=crash&short_desc_type=allwordssubstr

That shows 68 open GDB bugs with "crash" in the summary.  Some of them
are likewise crashes that make GDB not even start.  Are you going to
propose wrapping all of GDB's modules for those?  E.g., some are (and
I'm sure there are more) in the dwarf reader code.  Are we wrapping
that to dump the dwarf?  Seems like only one, maybe two are still
relevant demangler crashes, even.  And I don't see a huge number of
users adding themselves to CC on those bugs.

Looking at Tom's example crash from gcc 61233, the crash is due to
stack exhaustion due to seemingly infinite recursion.  Even if the
main bug is not fixed, I'd think it'd be easy to add a recursion
limit to the demangler, and thus prevent the crash, until whatever
c++11 feature that's still not well developed is handled properly.

I just can't/won't believe there are that many unindentified
bugs in the demangler.  If that were true, we'd hear _much_ more
about them.

And I bet that that if we took all the time we already collectively
spent these past weeks discussing this already and used it to
write that recursion-limiter patch, it'd be upstream already.  :-)

It's clear to me that we need to do something
demangler-development-process-wise to prevent these sorts
of bugs from manifesting only late in GDB, and I think we should
definitely get in contact with the GCC folks about it.

I had another idea to aid demangler testing with g++.
I had suggested before to run the demangler through the binaries
produced by g++'s testsuite.  The whole point here is to validate the
mangling as close as possible to the generator.
The alternative idea is to teach g++ itself to try to demangle any
symbol it generates/mangles (off by default, under a --param switch
or some such).  A sort of making-it-very easy-to-eat-your-own-dog-food
methodology.
We could then just run g++'s testsuite with that enabled.  No other
infrastructure would be necessary.  And, we could ask g++ maintainers
to do that once in a while, and perhaps run it through whatever usual
set of complicated C++ codebases they usually test g++ with.

-- 
Pedro Alves