apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: svn commit: rev 2017 - trunk/subversion/libsvn_subr
Date Mon, 27 May 2002 01:52:24 GMT
[Moved this back to dev@subversion since this is not an APR problem]

Sander

> From: Philip Martin [mailto:pm@localhost]On Behalf Of Philip Martin
> Sent: 27 May 2002 03:13

> striker@tigris.org writes:
> 
> > Author: striker
> > Date: 2002-05-26 09:27 GMT
> > New Revision: 2017
> > 
> > Modified:
> >    trunk/subversion/libsvn_subr/svn_error.c
> > Log:
> > * subversion/libsvn_subr/svn_error.c
> > 
> >   (svn_pool_create): Use the new functionality in APR to set
> >     a maximum on the total amount of memory kept in the freelist.
> >     I've choosen to set it to 4MB without any justification, so
> >     it might very well be that this number needs to be tweaked.
> > 
> >     For a bit of background on this change, see:
> >     
> >       http://subversion.tigris.org/servlets/ReadMsg?msgId=73898&listName=dev
> 
> Since this change the Subversion regression tests are failing when
> compiled with APR_POOL_DEBUG=1.  They hang in svn_pool_clear() when it
> recreates the Subversion error pool. 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.
> 
> -- 
> Philip


Mime
View raw message