From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17049 invoked by alias); 22 May 2014 14:13:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17037 invoked by uid 89); 22 May 2014 14:13:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 May 2014 14:13:39 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4MED2rF003784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 May 2014 10:13:02 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4MECxPx011741; Thu, 22 May 2014 10:13:00 -0400 Message-ID: <537E05EB.7090807@redhat.com> Date: Thu, 22 May 2014 14:13:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gary Benson , Joel Brobecker CC: Tom Tromey , Stan Shebs , gdb-patches@sourceware.org, Florian Weimer , Mark Kettenis Subject: Re: [PATCH 0/2] Demangler crash handler References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> <87ppj8s7my.fsf@fleche.redhat.com> <537BA194.904@earthlink.net> <87tx8kqm3o.fsf@fleche.redhat.com> <20140520202311.GK22822@adacore.com> <20140522125617.GB15598@blade.nx> In-Reply-To: <20140522125617.GB15598@blade.nx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00546.txt.bz2 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