From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7969 invoked by alias); 22 May 2014 13:18:04 -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 7955 invoked by uid 89); 22 May 2014 13:18:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 13:18:02 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4MDHvsX006587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 May 2014 09:17:58 -0400 Received: from blade.nx (ovpn-116-100.ams2.redhat.com [10.36.116.100]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4MDHuNS026883; Thu, 22 May 2014 09:17:57 -0400 Received: by blade.nx (Postfix, from userid 1000) id 3B912262414; Thu, 22 May 2014 14:17:56 +0100 (BST) Date: Thu, 22 May 2014 13:18:00 -0000 From: Gary Benson To: Stan Shebs Cc: Florian Weimer , Mark Kettenis , Pedro Alves , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140522131756.GC15598@blade.nx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537BA194.904@earthlink.net> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00544.txt.bz2 Stan Shebs wrote: > 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. Apart from the ones the fuzzer found, the recent crashes [1] all seem to have C++11 features, specifically, lambdas or lvalue references or both. My suspicion is that these bugs are being shaken out as C++11 code becomes more widespread and/or people are doing more complicated things with it. > 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. For sure, but somebody needs to write those tests, and that somebody needs 1) a deep knowledge of C++, including C++11, 2) a deep knowledge of the mangling scheme, and 3) the time and inclination to sit down and compile an extensive test suite. I don't know anybody with three out of three. Thanks, Gary -- [1] https://github.com/gbenson/binutils-gdb/blob/demangler/segfault-test.tests