You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ian Holsman <ia...@apache.org> on 2002/09/04 05:41:57 UTC

pool debug question.

hi all.
I've got a piece of multi-threaded code which runs fine
until it gets to the apr_terminate, where it segfaults in
apr_allocator_destroy.

any hints on what is going on ?
the test program is creating and destroying thousands of pools
but is not messing at all with allocators


Re: pool debug question.

Posted by rb...@apache.org.
> > apr_initialize calls apr_pool_initialize which creates a
> > global allocator which is used for all pools (unless overridden).
> > The global allocator is protected by a mutex, which is allocated
> > out of the global pool (also created by apr_pool_initialize).
> > 
> > apr_terminate calls apr_pool_terminate which in turn destroys
> > the global pool.  The global pool is the owner of the global
> > allocator and thus destroys the global allocator after its own
> > destruction.  The global pool cleanup _should_ already have
> > taken care of the destruction of the mutex and the resetting of
> > the mutex field of the global allocator.
> > 
> > 
> >>the test program is creating and destroying thousands of pools
> >>but is not messing at all with allocators
> > 
> > 
> > Are you sure you are not calling apr_terminate before all threads
> > have finished?  If you are we have a nice thing to debug :(
> > 
> This could be the problem, as the program is creating/exiting threads
> several times. but I am 99.9% sure that they are all dead before I 
> terminate (this is what msvc's debugger shows me)
> 
> The code is on http://webperf.org/a2/prob/
> it's the start of a dynamically sizing mpm (it spawns more threads
> when the queue is getting bigger, longer term it will base it's decision 
> on response times)

You realize that we already have an MPM that increases the number of
threads based on queuse, correct?  The Perchild MPM comes directly from
Dexter, which is static processes/dynamic threads.  Yes, perchild has more
options, because it change change the user/group of each child, but if you
don't specify any user/group directives, it works just like what you are
describing.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------


Re: pool debug question.

Posted by Ian Holsman <ia...@apache.org>.
Sander Striker wrote:
>>From: Ian Holsman [mailto:ianh@apache.org]
>>Sent: 04 September 2002 05:42
> 
> 
>>hi all.
>>
>>I've got a piece of multi-threaded code which runs fine
>>until it gets to the apr_terminate, where it segfaults in
>>apr_allocator_destroy.
>>
>>any hints on what is going on ?
> 
> 
> apr_initialize calls apr_pool_initialize which creates a
> global allocator which is used for all pools (unless overridden).
> The global allocator is protected by a mutex, which is allocated
> out of the global pool (also created by apr_pool_initialize).
> 
> apr_terminate calls apr_pool_terminate which in turn destroys
> the global pool.  The global pool is the owner of the global
> allocator and thus destroys the global allocator after its own
> destruction.  The global pool cleanup _should_ already have
> taken care of the destruction of the mutex and the resetting of
> the mutex field of the global allocator.
> 
> 
>>the test program is creating and destroying thousands of pools
>>but is not messing at all with allocators
> 
> 
> Are you sure you are not calling apr_terminate before all threads
> have finished?  If you are we have a nice thing to debug :(
> 
This could be the problem, as the program is creating/exiting threads
several times. but I am 99.9% sure that they are all dead before I 
terminate (this is what msvc's debugger shows me)

The code is on http://webperf.org/a2/prob/
it's the start of a dynamically sizing mpm (it spawns more threads
when the queue is getting bigger, longer term it will base it's decision 
on response times)
> Sander
> 


RE: pool debug question.

Posted by Sander Striker <st...@apache.org>.
> From: Ian Holsman [mailto:ianh@apache.org]
> Sent: 04 September 2002 05:42

> hi all.
>
> I've got a piece of multi-threaded code which runs fine
> until it gets to the apr_terminate, where it segfaults in
> apr_allocator_destroy.
> 
> any hints on what is going on ?

apr_initialize calls apr_pool_initialize which creates a
global allocator which is used for all pools (unless overridden).
The global allocator is protected by a mutex, which is allocated
out of the global pool (also created by apr_pool_initialize).

apr_terminate calls apr_pool_terminate which in turn destroys
the global pool.  The global pool is the owner of the global
allocator and thus destroys the global allocator after its own
destruction.  The global pool cleanup _should_ already have
taken care of the destruction of the mutex and the resetting of
the mutex field of the global allocator.

> the test program is creating and destroying thousands of pools
> but is not messing at all with allocators

Are you sure you are not calling apr_terminate before all threads
have finished?  If you are we have a nice thing to debug :(

Sander