[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 2017 - trunk/subversion/libsvn_subr

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-05-27 03:13:10 CEST

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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 27 03:14:29 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.