Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4930F9DA7 for ; Fri, 3 Feb 2012 17:46:42 +0000 (UTC) Received: (qmail 33123 invoked by uid 500); 3 Feb 2012 17:46:41 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 32986 invoked by uid 500); 3 Feb 2012 17:46:40 -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 32978 invoked by uid 99); 3 Feb 2012 17:46:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Feb 2012 17:46:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of DRuggeri@primary.net designates 216.87.38.199 as permitted sender) Received: from [216.87.38.199] (HELO mail4.primary.net) (216.87.38.199) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Feb 2012 17:46:31 +0000 Received: from home.simonrage.com ([216.114.77.126]:59724 helo=[192.168.0.2]) by mail4.primary.net with esmtpa (Exim 4.63) (envelope-from ) id 1RtNCz-0006Fh-PY for dev@httpd.apache.org; Fri, 03 Feb 2012 11:46:10 -0600 Message-ID: <4F2C1D52.3060707@primary.net> Date: Fri, 03 Feb 2012 11:45:54 -0600 From: Daniel Ruggeri User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Segfault in openssl's err_cmp when using SSLCryptoDevice and new SSLProxyMachineCertificateChainFile References: <4F16F5E2.3020101@primary.net> <4F2ADDE3.2050106@primary.net> In-Reply-To: <4F2ADDE3.2050106@primary.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: X-The email account used to send this email was: DRuggeri@primary.net X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "mail4.primary.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 2/2/2012 1:02 PM, Daniel Ruggeri wrote: > Since this happens with every attempt to start, I suspect it has nothing > to do with the new directive and more to do with something I did on the > openssl build. [...] Content analysis details: (-2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Virus-Checked: Checked by ClamAV on apache.org On 2/2/2012 1:02 PM, Daniel Ruggeri wrote: > Since this happens with every attempt to start, I suspect it has nothing > to do with the new directive and more to do with something I did on the > openssl build. I was, indeed, doing something stupid. A build with openssl 1.0.0g replicates the behavior of 0.9.8g in that it fails when SSLProxyMachineCertificateChainFile is enabled. The annoying part is that (due to the error I get when running in dbx) I can get no useful information in a debug session from Solaris. ... so I've switched to RHEL and gdb and have interesting information. Under Linux, I get this error on init: [Fri Feb 03 10:56:21 2012] [error] Init: Failed to enable Crypto Device API `chil' [Fri Feb 03 10:56:21 2012] [error] SSL Library Error: 2164682852 error:81067064:CHIL engine:HWCRHK_INIT:already loaded [Fri Feb 03 10:56:21 2012] [error] SSL Library Error: 638287981 error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed This only happens when SSLProxyMachineCertificateChainFile is set.... With some quick debugging I see that the hwcrhk_finish DOES NOT get called during ssl_cleanup_pre_config... but DOES get called when the directive has been removed. To me, it looks like httpd has not registered the engine for cleanup, but that certainly shouldn't be impacted by this patch. It seems something in the process of loading the store is complicating things. I'll continue poking around, but pointers are certainly appreciated. -- Daniel Ruggeri