> From: Philip Martin
> Sent: 29 May 2002 16:04
>> "Sander Striker" <striker@apache.org> writes:
>> Hmmm, well, it _is_ evening now, but I don't really have the energy
>> to patch it up. If someone beats me to it, fine, otherwise just don't
>> run with apr pool debugging enabled for now.
>
> I'm using a patch that puts the mutex into the parent's pool. This
> allows APR_POOL_DEBUG to be used with Subversion. It's not a perfect
> solution due to the potential for unbounded memory use. It's good
> enough for me...
[...]
Ok, I like this patch somewhat better. Could you test it please?
Furthermore I think we have a problem in the production code aswell,
unless noone clears the top level pool in subversion (which would
cause the problem to show its ugly head). What is happening there
is that the mutex is created in the top level pool. So, if you
do:
p = svn_pool_create(p);
... pool operations on p
svn_pool_clear(p);
... pool operations on p
BOOM
Ofcourse the simple fix would be to implement svn_pool_clear as
somewhat more than a thin wrapper. However, if we can avoid it
(by not ever clearing the top level pool), that would have my
preference.
Sander
Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.169
diff -u -r1.169 apr_pools.c
--- memory/unix/apr_pools.c 26 May 2002 09:00:08 -0000 1.169
+++ memory/unix/apr_pools.c 29 May 2002 19:55:31 -0000
@@ -1381,6 +1381,17 @@
#endif /* (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE) */
pool_clear_debug(pool, file_line);
+
+
+#if APR_HAS_THREADS
+ /* If we had our own mutex, it will have been destroyed by
+ * the registered cleanups. Recreate the mutex.
+ */
+ if (pool->parent == NULL || pool->parent->mutex != pool->mutex) {
+ (void)apr_thread_mutex_create(&pool->mutex,
+ APR_THREAD_MUTEX_NESTED, pool);
+ }
+#endif /* APR_HAS_THREADS */
}
APR_DECLARE(void) apr_pool_destroy_debug(apr_pool_t *pool,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:23:47 2002