From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12004 invoked by alias); 22 May 2014 14:09:17 -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 11987 invoked by uid 89); 22 May 2014 14:09:16 -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; Thu, 22 May 2014 14:09:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4ME9Amq009418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 May 2014 10:09:10 -0400 Received: from blade.nx (ovpn-116-100.ams2.redhat.com [10.36.116.100]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4ME96B7008920; Thu, 22 May 2014 10:09:07 -0400 Received: by blade.nx (Postfix, from userid 1000) id EA619262414; Thu, 22 May 2014 15:09:04 +0100 (BST) Date: Thu, 22 May 2014 14:09:00 -0000 From: Gary Benson To: Tom Tromey Cc: Pedro Alves , Florian Weimer , Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140522140904.GD15598@blade.nx> References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> <87ppj8s7my.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ppj8s7my.fsf@fleche.redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00545.txt.bz2 Tom Tromey wrote: > Pedro> Then stealing a signal handler always has multi-threading > Pedro> considerations. E.g., gdb Python code could well spawn a > Pedro> thread that happens to call something that wants its own > Pedro> SIGSEGV handler... Signal handlers are per-process, not > Pedro> per-thread. > > That is true in theory but I think it is unlikely in practice. And, > should it happen -- well, the onus is on folks writing extensions > not to mess things up. That's the nature of the beast. And, sure, > it is messy, particularly if we ever upstream "import gdb", but even > so, signals are just fraught and this is not an ordinary enough > usage to justify preventing gdb from doing it. GDB installs handlers for INT, TERM, QUIT, HUP, FPE, WINCH, CONT, TTOU, TRAP, ALRM and TSTP, and some other platform-specific ones I didn't recognise. Is there anything that means SIGSEGV should be treated differently to all these other signals? > The choice is really between SEGV catching and "somebody else > down the road fixes more demangler bugs". The demangler bugs will get fixed one way or another. The choice is: do we allow users to continue to use GDB while the bug they've hit is fixed, or, do we make them wait? In the expectation that they will put their own work aside while they fix GDB instead? Thanks, Gary -- http://gbenson.net/