apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Creating an allocator with no mutex...
Date Fri, 18 Jul 2003 20:22:47 GMT
I think we just discovered what the real source of the problem is.  It
appears that apr_pool_create_ex() is trying to extract the mutex from
the wrong allocator when an allocator is specified.  When it tries to
get the mutex it uses the parent allocator if one was not passed in.  If
an allocator was passed in then it uses that one instead which is wrong.
 The mutex from the allocator that was passed in does not protect the
parent but the code still manipulates it anyway.  This means that two or
more threads could overwrite parent->child simply because the wrong
mutex was locked or no mutex was locked at all (in our case).  The call
to apr_allocator_mutex_get() should use "parent->allocator" not
"allocator".  If you look at apr_pool_destroy() it is doing it
correctly.  Otherwise this code is not thread safe.


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions

>>> Cliff Woolley <jwoolley@virginia.edu> Friday, July 18, 2003 1:17:21
PM >>>
On Fri, 18 Jul 2003, Brad Nicholes wrote:

>    Under what circumstances would you want to create an allocator
> without a mutex assigned to it?  We have been running into a problem
> with the NetWare MPM on multi-processor boxes where Apache faults
> periodically while trying to destroy the memory pool.  The fault

Jean-Jacques had written me off-list about the same problem a little
ago, and I just wrote back to him about that.  You create an allocator
with no mutex on it for a pool that will only ever be used to allocate
entities (including subpools) in the current thread.  In the other
it's true that each thread pool has no allocator mutex -- because that
thread pool will only ever allocate things for that one thread.  But
thread pool's parent, which is the process pool in most other MPM's,
have a mutex on it, meaning that sibling lists which are used when
creating and destroying new threads /are/ protected by mutex.  I'm
guessing that what you're seeing is that, since netware has no
the one thread that handles creation of other threads has a thread
(of which the other threads' pools are children) that is missing the
it ought to have.

I could be wrong though, as my cursory glance through worker and
the netware mpm just now did not reveal where the mutex ought to be
Unfortunately I'm on my way out of town for the weekend right now or
look into it more.

Hopefully Sander can fill in to the extent that I'm full of shit.  :)


View raw message