From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5465 invoked by alias); 15 May 2014 13:27:09 -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 5454 invoked by uid 89); 15 May 2014 13:27:08 -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, 15 May 2014 13:27:07 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4FDR3bt004810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 May 2014 09:27:04 -0400 Received: from blade.nx (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4FDR2n2007215; Thu, 15 May 2014 09:27:03 -0400 Received: by blade.nx (Postfix, from userid 1000) id 2A78A2623DD; Thu, 15 May 2014 14:27:02 +0100 (BST) Date: Thu, 15 May 2014 13:27:00 -0000 From: Gary Benson To: Pedro Alves Cc: Florian Weimer , Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140515132702.GE13323@blade.nx> References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53737737.2030901@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00227.txt.bz2 Pedro Alves wrote: > ...stealing a signal handler always has multi-threading > considerations. E.g., gdb Python code could well spawn a thread > that happens to call something that wants its own SIGSEGV handler... > Signal handlers are per-process, not per-thread. I had not considered this. Do you know of any specific libraries that do it? The only times I've seen SIGSEGV handlers in the wild have been in VMs and other language-level stuff. Thanks, Gary -- http://gbenson.net/