From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23685 invoked by alias); 20 May 2014 18:40:28 -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 23674 invoked by uid 89); 20 May 2014 18:40:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-masked.atl.sa.earthlink.net Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 May 2014 18:40:26 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wmoxc-0001d5-RD for gdb-patches@sourceware.org; Tue, 20 May 2014 14:40:24 -0400 Message-ID: <537BA194.904@earthlink.net> Date: Tue, 20 May 2014 18:40:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org 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> In-Reply-To: <87ppj8s7my.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94041da06f20cf36801a3245bc5e7377a40350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00440.txt.bz2 On 5/20/14, 10:05 AM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves 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