From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9971 invoked by alias); 10 Jul 2007 18:47:03 -0000 Received: (qmail 9964 invoked by uid 22791); 10 Jul 2007 18:47:03 -0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from sccrmhc15.comcast.net (HELO sccrmhc15.comcast.net) (204.127.200.85) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jul 2007 18:46:56 +0000 Received: from gateway.sf.frob.com (c-67-160-211-197.hsd1.ca.comcast.net[67.160.211.197]) by comcast.net (sccrmhc15) with ESMTP id <2007071018465501500j4ju2e>; Tue, 10 Jul 2007 18:46:55 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9324C357B; Tue, 10 Jul 2007 11:46:53 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id A1F904D0585; Tue, 10 Jul 2007 11:46:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: frysk@sourceware.org Subject: Re: elfutls using assert In-Reply-To: Andrew Cagney's message of Tuesday, 10 July 2007 11:34:14 -0400 <4693A6F6.8030403@redhat.com> X-Zippy-Says: Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED! Message-Id: <20070710184623.A1F904D0585@magilla.localdomain> Date: Tue, 10 Jul 2007 18:47:00 -0000 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00075.txt.bz2 > Unless I'm mistaken, it isn't possible to attach the abort signal as it > may be sent to any thread? You are mistaken. If you are catching the signal, you will catch all such signals in whatever thread they are delivered. Anyway, abort is equivalent to raise (SIGABRT), which means synchronously to the calling thread (the signal will appear to happen immediately after the syscall instruction for the syscall that performs the "raise"). > Anyway, to make the problem more concrete, when a panic like this occurs, > frysk needs time to pull all inserted breakpoints before detaching from > the program and exiting. Like I said, when one of these hits, you are lucky if all memory is not randomly clobbered already. But if you just avoid anything that would call into elfutils libs at all, you might be avoiding the memory that is definitely clobbered already, and be lucky enough to survive long enough to withdraw gracefully. Thanks, Roland