From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16034 invoked by alias); 4 Jun 2014 13:34:24 -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 16023 invoked by uid 89); 4 Jun 2014 13:34:23 -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; Wed, 04 Jun 2014 13:34:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s54DYGiX001374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 Jun 2014 09:34:16 -0400 Received: from blade.nx (ovpn-116-110.ams2.redhat.com [10.36.116.110]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s54DYEk4022820; Wed, 4 Jun 2014 09:34:15 -0400 Received: by blade.nx (Postfix, from userid 1000) id A685C26243E; Wed, 4 Jun 2014 14:34:13 +0100 (BST) Date: Wed, 04 Jun 2014 13:34:00 -0000 From: Gary Benson To: Mark Kettenis Cc: gdb-patches@sourceware.org, aburgess@broadcom.com, xdje42@gmail.com, eliz@gnu.org, fw@deneb.enyo.de, palves@redhat.com, tromey@redhat.com Subject: Re: [PATCH 0/2 v3] Demangler crash handler Message-ID: <20140604133413.GA10121@blade.nx> References: <20140604100755.GA7570@blade.nx> <201406041027.s54ARXYL017073@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406041027.s54ARXYL017073@glazunov.sibelius.xs4all.nl> X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00159.txt.bz2 Mark Kettenis wrote: > > From: Gary Benson > > Is this ok to commit? > > Not for me. You're running too much code between entering the > SIGSEGV handler and dumping core for my taste. I don't understand. This is the signal handler: static void gdb_demangle_signal_handler (int signo) { static int core_dumped = 0; if (!core_dumped) { if (fork () == 0) dump_core (); core_dumped = 1; } SIGLONGJMP (gdb_demangle_jmp_buf, signo); } and this is dump_core: void dump_core (void) { #ifdef HAVE_SETRLIMIT struct rlimit rlim = { RLIM_INFINITY, RLIM_INFINITY }; setrlimit (RLIMIT_CORE, &rlim); #endif /* HAVE_SETRLIMIT */ abort (); /* NOTE: GDB has only three calls to abort(). */ } This is what happens: 1. the signal handler is entered 2. fork 3. setrlimit 4. abort I could remove the setrlimit but presumably somebody added that to make a successful core dump more likely. Would you accept this patch if I changed the dump_core to abort in gdb_demangle_signal_handler? (and updated all the comments about having only three calls to abort)? > I still very much agree with Pedro; this should not be necessary. "Should" is the operative word here. It *should* not be necessary because the demangler *should* never crash. But this isn't utopia. The demangler is code, and code has bugs. People make mistakes. Things are valid now that may not be valid in the future. And GDB should not just crash if some symbol in the inferior isn't handled or doesn't make sense or whatever. > Drop this. Spend your time on fixing the actual bugs. Are you trying to tell me you will never approve a patch that installs a SIGSEGV handler across demangler calls? Thanks, Gary -- http://gbenson.net/