From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31021 invoked by alias); 11 May 2014 05:10:52 -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 30996 invoked by uid 89); 11 May 2014 05:10:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f45.google.com Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 11 May 2014 05:10:46 +0000 Received: by mail-yh0-f45.google.com with SMTP id b6so5209246yha.4 for ; Sat, 10 May 2014 22:10:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.26.193 with SMTP id c41mr29074750yha.151.1399785044027; Sat, 10 May 2014 22:10:44 -0700 (PDT) Received: by 10.170.222.7 with HTTP; Sat, 10 May 2014 22:10:43 -0700 (PDT) In-Reply-To: <87fvkhjqvs.fsf@mid.deneb.enyo.de> References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> Date: Sun, 11 May 2014 05:10:00 -0000 Message-ID: Subject: Re: [PATCH 0/2] Demangler crash handler From: Doug Evans To: Florian Weimer Cc: Mark Kettenis , gbenson@redhat.com, "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00127.txt.bz2 On Sat, May 10, 2014 at 1:55 PM, Florian Weimer wrote: > * 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. gdb can demangle a lot of symbols. I'd be worried about the performance. > What's so difficult about fixing the demangler? It's not a question of not fixing the demangler. It's a question of improving the gdb user experience. gdb segfaults in the middle of a debugging session ARE BAD. gdb's just a tool for solving problems, I'd rather it be robust. Note that gdb has for a long time given the user the option of continuing the debugging session after an internal error, instead of just going straight to a core dump. Demangler segv handling is no different, and if people feel the problem is sufficient to warrant taking this step (and assuming any technical problems are solvable), I'm ok with it. [Whether there are intractable technical problems here I will leave to a separate thread/subthread. Offhand I don't know.] As for worries about demangler bugs being less often fixed ... it's not clear to me that would be the case. How often would we get actionable segfault reports vs reports that specifically say "the demangler is busted, and here's the string that triggers the problem" ?