From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28156 invoked by alias); 10 May 2014 20:55:14 -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 28136 invoked by uid 89); 10 May 2014 20:55:14 -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 autolearn=ham version=3.3.2 X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (46.237.207.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 10 May 2014 20:55:12 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1WjEIR-00032v-Sk; Sat, 10 May 2014 22:55:03 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WjEIR-0006N6-L2; Sat, 10 May 2014 22:55:03 +0200 From: Florian Weimer To: Mark Kettenis Cc: gbenson@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> Date: Sat, 10 May 2014 20:55:00 -0000 In-Reply-To: <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Fri, 9 May 2014 13:20:24 +0200 (CEST)") Message-ID: <87fvkhjqvs.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00126.txt.bz2 * Mark Kettenis: > No. It's this skind of duct-tape that will make sure that bugs in the > demangler won't get fixed. Apart from removing the incentive to fix > the bugs, these SIGSEGV signal handlers make actually fixing the bugs > harder as you won't have core dumps. I find this approach extremely odd as well. > 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. It would be more reliable to run the demangler in a separate process. What's so difficult about fixing the demangler?