From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10009 invoked by alias); 6 Jun 2014 21:12:36 -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 9995 invoked by uid 89); 6 Jun 2014 21:12:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-gw2-out.broadcom.com Received: from mail-gw2-out.broadcom.com (HELO mail-gw2-out.broadcom.com) (216.31.210.63) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jun 2014 21:12:34 +0000 Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw2-out.broadcom.com with ESMTP; 06 Jun 2014 14:15:29 -0700 Received: from IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 6 Jun 2014 14:12:32 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) with Microsoft SMTP Server id 14.3.174.1; Fri, 6 Jun 2014 14:12:32 -0700 Received: from [10.177.252.207] (unknown [10.177.252.207]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id BD1A19F9F7; Fri, 6 Jun 2014 14:12:30 -0700 (PDT) Message-ID: <53922EBD.7030300@broadcom.com> Date: Fri, 06 Jun 2014 21:12:00 -0000 From: Andrew Burgess User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gary Benson , CC: Doug Evans , Eli Zaretskii , "Florian Weimer" , Mark Kettenis , "Pedro Alves" , Tom Tromey Subject: Re: [PATCH 3/3 v4] Demangler crash handler References: <20140605130140.GA20572@blade.nx> <20140605130358.GD20572@blade.nx> In-Reply-To: <20140605130358.GD20572@blade.nx> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00339.txt.bz2 On 05/06/2014 2:03 PM, Gary Benson wrote: > diff --git a/gdb/cp-support.c b/gdb/cp-support.c > index 91533e8..f4dde70 100644 > --- a/gdb/cp-support.c > +++ b/gdb/cp-support.c > + > +/* Signal handler for gdb_demangle. */ > + > +static void > +gdb_demangle_signal_handler (int signo) > +{ > + if (gdb_demangle_attempt_core_dump) > + { > + if (fork () == 0) > + dump_core (); This worries me a little, when a problem case occurs gdb will dump core regardless of the users ulimit setting, without first asking the user, and doesn't tell the user that a core file was created. This feels quite unexpected behaviour to me, especially the bit about disregarding the ulimit setting without first asking for permission. Catching the crash feels like a good idea, but I'd prefer that gdb ask before circumventing the ulimit and dumping core. Alternatively we could just not dump core from gdb, report the bad symbol and let the user file a bug. With the demangler being so deterministic it should be possible to reproduce, if not, then we just ask the user to turn off the crash catch, adjust their ulimit (like we would with any other gdb SEGV crash), and rerun the test. If we really want to create the core file by default, but aren't going to ask, then I'd propose we honour the ulimit setting, and make sure that the user is told that a core file was just written. Thanks, Andrew