From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21551 invoked by alias); 24 May 2011 11:38:10 -0000 Received: (qmail 21538 invoked by uid 22791); 24 May 2011 11:38:09 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk) (131.111.8.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 May 2011 11:37:52 +0000 Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51102) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1QOpvr-0003qT-Wi (Exim 4.72) (return-path ); Tue, 24 May 2011 12:37:51 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1QOpvr-0004jl-4D (Exim 4.67) (return-path ); Tue, 24 May 2011 12:37:51 +0100 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 24 May 2011 12:37:51 +0100 Date: Tue, 24 May 2011 13:19:00 -0000 From: "N.M. Maclaren" To: gfortran List , gcc-patches@gcc.gnu.org Subject: Re: [Patch, libfortran] PR 48931 Async-signal-safety of backtrace signal handler Message-ID: In-Reply-To: <2FD97A4D-2A6B-4DDB-888E-E32F9B93424B@gmail.com> References: <2FD97A4D-2A6B-4DDB-888E-E32F9B93424B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg01715.txt.bz2 On May 24 2011, FX wrote: > >> One solution could be to search the PATH for addr2line during library >> initialization (where we don't need to be async-signal-safe), and then >> store it somewhere and use it in show_backtrace(). > > That's one way. Another way is just to store a copy of the PATH during > initialization, and only search addr2line when really needed (which can > be done with a static buffer and a series of call to execve(), can't it?) Well, yes, but it is better design to do as little as possible in such handlers. No matter what POSIX says, calling fork or exec is intrinsically problematic - for example, ANY signal (including SIGCONT!) can cause chaos if it is received in such circumstances, and the actual rules for which processes get which signals are foul beyond belief, even when the term 'rules' makes sense :-( That favours Janne's approach. Regards, Nick Maclaren.