apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <phi...@codematters.co.uk>
Subject Re: svn commit: rev 2017 - trunk/subversion/libsvn_subr
Date Tue, 28 May 2002 13:28:08 GMT
"Sander Striker" <striker@apache.org> writes:

> > Essentially the Subversion code
> > does this
> > 
> >   apr_pool_clear_debug (some_pool, file_line);
> >   apr_pool_create_ex(error_pool, some_pool, abort_on_pool_failure, NULL);
> > 
> > The problem is that when some_pool was originally created by
> > apr_pool_create_ex() a mutex was created which was allocated within
> > some_pool itself.  When apr_pool_clear_debug is called it free's all
> > the allocated memory including the memory used for mutex.  Thus any
> > further attempt to use some_pool, such as for the parent of the new
> > error_pool, may fail when attempting the lock some_pool's mutex. The
> > Subversion regression tests hang attempting to lock this mutex.
>
> [Moved this back to dev@subversion since this is not an APR problem]

I fail to see why this is not an APR problem (perhaps I confused you
by writing apr_pool_create_ex above, but when APR_POOL_DEBUG is set
that function is defined to be apr_pool_create_ex_debug.)  Calling
apr_pool_create_ex_debug creates a mutex in the pool, calling
apr_pool_clear_debug destroys and free's the mutex, but leaves the
member variable pointing to the destroyed resource.  In this state the
pool is broken.

As far as I can see, apr_pool_clear_debug must either recreate the
mutex or not destroy it in the first place.  Now, destroying and
recreating it might not be safe, given that the mutex is used in
apr_pool_walk_tree.  So it appears that the solution must be for the
mutex to persist for the lifetime of the pool.  It's not immediately
clear to me how best to achieve this.

-- 
Philip

Mime
View raw message