Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 15258 invoked from network); 15 Jan 2009 20:17:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Jan 2009 20:17:39 -0000 Received: (qmail 69913 invoked by uid 500); 15 Jan 2009 20:17:35 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 69864 invoked by uid 500); 15 Jan 2009 20:17:35 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 69855 invoked by uid 99); 15 Jan 2009 20:17:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Jan 2009 12:17:35 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 15 Jan 2009 20:17:33 +0000 Received: (qmail 14981 invoked by uid 2161); 15 Jan 2009 20:17:12 -0000 Received: from [192.168.2.4] (euler.heimnetz.de [192.168.2.4]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 849A71721C for ; Thu, 15 Jan 2009 21:17:01 +0100 (CET) Message-ID: <496F99C9.9090400@apache.org> Date: Thu, 15 Jan 2009 21:17:13 +0100 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: mod_backtrace and mod_whatkilledus to trunk? References: <00163630ee1d443a1004608886e9@google.com> <496F7201.2030901@webthing.com> <99EA83DCDE961346AFA9B5EC33FEC08B01A05A52@VF-MBX11.internal.vodafone.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 01/15/2009 07:39 PM, Jeff Trawick wrote: > On Thu, Jan 15, 2009 at 12:40 PM, "Pl�m, R�diger, VF-Group" < > ruediger.pluem@vodafone.com> wrote: >> >> Another option would be to add this hook by default and prevent its >> execution by a directive (haven't dug into this to check if this is >> possible). > > > which reminds me: The 2.x hook is already protected both by a configure > option which defaults to no and a directive which defaults to Off ;) > > See http://httpd.apache.org/docs/2.2/mod/mpm_common.html#enableexceptionhook > > See some comments from Joe about why not to even allow the directive by > default at https://bugzilla.redhat.com/show_bug.cgi?id=205627 Thanks for the pointer. I agree with Joe that it is better to analyse the core dump afterwards, but I don't see that setting AP_ENABLE_EXCEPTION_HOOK and setting EnableExceptionHook to Off really hurts us in this respect. We already catch "core dump signals" to change the current working dir to dump the core in the correct place. If EnableExceptionHook is set to Off we just call one additional static function (run_fatal_exception_hook) and check a static variable in an if statement. We could even integrate the code of run_fatal_exception_hook into sig_coredump without any pain. So from my current point of view I tend to say: enable enableexceptionhook by default and let EnableExceptionHook default to off (as currently). But Joe has always very good arguments, so he may make me change my mind again :-). Regards R�diger