This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Demangler crash handler
- From: Pedro Alves <palves at redhat dot com>
- To: Gary Benson <gbenson at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Stan Shebs <stanshebs at earthlink dot net>, gdb-patches at sourceware dot org, Florian Weimer <fw at deneb dot enyo dot de>, Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Date: Thu, 22 May 2014 15:12:59 +0100
- Subject: Re: [PATCH 0/2] Demangler crash handler
- Authentication-results: sourceware.org; auth=none
- References: <20140509100656 dot GA4760 at blade dot nx> <201405091120 dot s49BKO1f010622 at glazunov dot sibelius dot xs4all dot nl> <87fvkhjqvs dot fsf at mid dot deneb dot enyo dot de> <53737737 dot 2030901 at redhat dot com> <87ppj8s7my dot fsf at fleche dot redhat dot com> <537BA194 dot 904 at earthlink dot net> <87tx8kqm3o dot fsf at fleche dot redhat dot com> <20140520202311 dot GK22822 at adacore dot com> <20140522125617 dot GB15598 at blade dot nx>
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