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: Stan Shebs <stanshebs at earthlink dot net>
- To: gdb-patches at sourceware dot org
- Date: Tue, 20 May 2014 11:40:20 -0700
- 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>
On 5/20/14, 10:05 AM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> I have to admit I'm not super keen on using signals for this either.
>
> Pedro> For one, not all bugs trigger segmentation faults.
>
> That is true, but the goal of the patch is to cheaply improve gdb's
> behavior in some failure modes, not to solve every problem.
>
> I think this is warranted due to known properties of the demangler.
> First, it is complicated. Second, it is hard to test well. Third,
> there's been a history of new demangler features being rolled out with
> insufficient testing, and we can reasonably expect that to continue.
> Fourth, the bugs in question have a very severe effect on gdb users --
> you simply cannot debug -- whereas the effect on other users of the
> demangler is slight (this is why I think we can expect to see more
> demangler bugs of a similar nature).
After reading all the discussion, I'm tending to disfavor catching
demangler segfaults.
My memory may be playing tricks on me, but once upon a time it seemed
like the demangler was the most reliable part of the mixed bag that was
C++ debugging - segfaults were pretty much unheard of. So it's a little
strange to me that it's now become so troublesome that it needs to be
wrapped, or has been suggested, to be run in a different process(!), and
it reinforces Mark K's original point about signal catchers masking more
serious problems.
Complicated or not, the demangler is one of the most algorithmically
predictable components of GDB, and it is very easy to test
comprehensively; no races, no arcane target dependencies, textual
input and output. So if it's becoming unreliable, perhaps there are
process flaws that we should be addressing.
Stan
stan@codesourcery.com