Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Fri, 5 Jan 2001 16:52:54 -0800 (PST)
From: rbb@covalent.net
To: new-httpd@apache.org
cc: dev@apr.apache.org
Subject: Re: APR Bug or misunderstanding ?
In-Reply-To: <3A56474A.78289C82@level8.com>
Message-ID: <Pine.LNX.4.21.0101051643070.5124-100000@koj>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


(Copied to dev@apr.apache.org, which is the APR development mailing list.)

>     I've been having a look at the new APR library on NT. To cut a long story short
> I ended up with a program that did: apr_initialize() followed immediately by
> apr_terminate(). The program blew up in the terminate call.
>     After some checking I found that the poblem appeared the following:
>         apr_term_alloc() destroyes the alloc_mutex and then issues
> apr_destroy_pool(globalp);
>     Now inside apr_destroy_pool() it attempted to acquire the alloc_mutex lock.
> This had already been destroyed, hence the system (rightly) complained.
>     I inverted the order of the operations in apr_term_alloc() so that the pool is
> destroyed before the mutexes are destroyed.

#1.  Thank you for diagnosing this problem.  I have not seen it, but
having reviewed the code, you are 100% correct.  Your solution is slightly
flawed, but I am about to commit a different fix.

The problem with your solution is very odd, and is unlikely to happen, but
we can't just change the order.  Basically, the alloc_mutex and the
spawn_mutex are allocated out of the globalp pool, so when we destroy
those pools, the mutexes go away too.  This leaves a time, when we could
be destroying the globalp pool, without mutexes, even though we have
multiple pools.  I am surprised your fix worked, because I would have
thought the destroy_lock calls would have seg faulted, since those mutexes
would have been freed when the pool was destroyed.

The fix I will commit instead, will check to ensure that there are locks
when we destroy a pool.  This will add two if's to the destroy_pool call,
but I believe this is the safer option.

Again, thank you for the thorough diagnosis, it makes this very easy to
fix.  Please let us know if you have any other problems with APR.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------