From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3291 invoked by alias); 13 May 2014 10:22:31 -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 3280 invoked by uid 89); 13 May 2014 10:22:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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; Tue, 13 May 2014 10:22:29 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4DAMPYm002221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 May 2014 06:22:25 -0400 Received: from blade.nx (ovpn-116-68.ams2.redhat.com [10.36.116.68]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4DAMNJL024263; Tue, 13 May 2014 06:22:24 -0400 Received: by blade.nx (Postfix, from userid 1000) id 4DF8026234A; Tue, 13 May 2014 11:22:23 +0100 (BST) Date: Tue, 13 May 2014 10:22:00 -0000 From: Gary Benson To: Florian Weimer Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140513102223.GC17805@blade.nx> References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fvkhjqvs.fsf@mid.deneb.enyo.de> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00153.txt.bz2 Florian Weimer wrote: > * Mark Kettenis: > > Besides, any signal handler that does more than just setting a > > flag is probably broken. Did you verify that you only call > > async-signal-safe functions in the signal handler code path? > > At least it doesn't make things much worse because the program is > already in a funny state when the signal is generated. Yes. I'm not aiming for perfection, I was merely looking for simple ways to get some protection from the kind of crashes I've observed. > It would be more reliable to run the demangler in a separate > process. Agreed. There are two issues though. First is performance: GDB can demangle a lot of symbols--starting GDB on LibreOffice demangles more than 369,000 symbols on my machine, and typing "b " demangles 2,740,000 more--so the IPC overhead has to be seriously low. The second issue is my time. I could spare the time to write a simple, low-LOC patch like this, but if the only acceptable solution is the demangler in a separate process then that has to be way down my priority list--especially given that that solution would likely be rejected on performance grounds. I'm pretty sure there are people on this list for whom any loss of performance would be unacceptable. > What's so difficult about fixing the demangler? It's not so difficult really, but fixes take time to diagnose, reproduce, fix, test, review, etc. During that interval the user cannot use GDB to debug their program. This patch is about allowing the user the possibility of getting their work done. Cheers, Gary -- http://gbenson.net/