[Moved this back to [EMAIL PROTECTED] since this is not an APR problem] Sander
> From: Philip Martin [mailto:[EMAIL PROTECTED] Behalf Of Philip Martin > Sent: 27 May 2002 03:13 > [EMAIL PROTECTED] 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
