apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: apr/memory/unix apr_pools.c
Date Tue, 09 Dec 2003 18:41:19 GMT
  That seems reasonable to me.  We discovered the problem with mod_jk2. 
The code was traversing the pool hierarchy back to the root where they
proceded to create a mutex and set a cleanup.  Since the the APR
global_pool is never cleaned up from the root down while APR is in use,
the mutex was allowed to hang around even after httpd had gone away. 
Since the mutex was actually allocated against httpd, but httpd no
longer existed in memory, NetWare faulted when APR attempted to destroy
the orphaned mutex.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> Sander Striker <striker@apache.org> Tuesday, December 09, 2003
11:01:54 AM >>>
On Tue, 2003-12-09 at 18:43, bnicholes@apache.org wrote:
> bnicholes    2003/12/09 09:43:01
> 
>   Modified:    memory/unix apr_pools.c
>   Log:
>   Since all NetWare memory is shared, allowing an application access
to the APR global pool allows it to allocate memory and set cleanups
that will never happen even if the application terminates.
>   

>I'm wondering if we shouldn't always decline to return the global
pool.
>No user should be messing with the apr global pool anyway.
>
>Thoughts?
>
>Sander

Mime
View raw message