From dev-return-24689-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Feb 7 00:01:01 2012 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-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 6DB499B7B for ; Tue, 7 Feb 2012 00:01:01 +0000 (UTC) Received: (qmail 31525 invoked by uid 500); 7 Feb 2012 00:01:01 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31444 invoked by uid 500); 7 Feb 2012 00:01:00 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31434 invoked by uid 99); 7 Feb 2012 00:01:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 00:01:00 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of ronen@tversity.com does not designate 209.85.220.178 as permitted sender) Received: from [209.85.220.178] (HELO mail-vx0-f178.google.com) (209.85.220.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 00:00:53 +0000 Received: by vcbfk1 with SMTP id fk1so5755563vcb.37 for ; Mon, 06 Feb 2012 16:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tversity.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TK+h/tqcL9xqU9chmvcSkggzt9k4ainXmd3zWd2H5vs=; b=gURGI7/OgGH+lfUitfALkthK7v25k0yMnW8EEauKM+h79XJRiVJDtEXzLdwQv412R+ Mr7zvbtCYtupiw1CZMPcNHk+YP1R6WOz2eKZ0qhFs02zD58W+1gSM9eEN/wZSGoFet8W qZwNhUCXbFTeT/HxgkI6URtOXAwmcSL/PwLsk= MIME-Version: 1.0 Received: by 10.220.227.7 with SMTP id iy7mr11217424vcb.53.1328572832193; Mon, 06 Feb 2012 16:00:32 -0800 (PST) Received: by 10.220.186.7 with HTTP; Mon, 6 Feb 2012 16:00:32 -0800 (PST) In-Reply-To: <1328572491.2059.12.camel@shrek.rexursive.com> References: <1328572491.2059.12.camel@shrek.rexursive.com> Date: Mon, 6 Feb 2012 19:00:32 -0500 Message-ID: Subject: Re: Crash in apr_proce_create() From: Ronen Mizrahi To: Bojan Smojver Cc: dev@apr.apache.org Content-Type: multipart/alternative; boundary=14dae9cdc90fb89c5604b8547711 X-Virus-Checked: Checked by ClamAV on apache.org --14dae9cdc90fb89c5604b8547711 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 6, 2012 at 6:54 PM, Bojan Smojver wrote: > On Mon, 2012-02-06 at 18:47 -0500, Ronen Mizrahi wrote: > > For the time being we resolved it by adding an if not NULL statement > > before invoking the cleanup function however I am not sure that a NULL > > cleanup function is allowed or by itself represents some kind of an > > issue. > > Have you tried setting you cleanup function to apr_pool_cleanup_null()? > See: > > > http://apr.apache.org/docs/apr/1.4/group___pool_cleanup.html#gaa211acee585df08f396a50b0ea489b02 > > -- > Bojan > > I am afraid I do not understand how this is relevant. The pool cleanup functions in the parent process are registered correctly and work fine even when releasing the global pool (which happens when the process terminates). Only in the child process we run into this issue and we cannot change the registrations of cleanup functions in the child process since the crash occurs somewhere between the invocation of fork() and the invocation of exec(). Ronen --14dae9cdc90fb89c5604b8547711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 6, 2012 at 6:54 PM, Bojan Sm= ojver <bojan@re= xursive.com> wrote:
On Mon, 2012-02-06 at 18:47 -0500, Ronen Mizrahi wrote: > For the time being we resolved it by adding an if not NULL statement > before invoking the cleanup function however I am not sure that a NULL=
> cleanup function is allowed or by itself represents some kind of an > issue.

Have you tried setting you cleanup function to apr_pool_cleanup_null(= )?
See:

http://apr.apache.org/do= cs/apr/1.4/group___pool_cleanup.html#gaa211acee585df08f396a50b0ea489b02=

--
Bojan


I am afraid I do not und= erstand how this is relevant.

The pool cleanup fun= ctions in the parent process are registered correctly and work fine even wh= en releasing the global pool (which happens when the process terminates).

Only in the child process we run into this issue and we= cannot change the registrations of cleanup functions in the child process = since the crash occurs somewhere between the invocation of fork() and the i= nvocation of exec().

Ronen

--14dae9cdc90fb89c5604b8547711--