Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 42051 invoked by uid 500); 28 May 2002 13:28:10 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 42040 invoked from network); 28 May 2002 13:28:10 -0000 To: "Sander Striker" Cc: Subject: Re: svn commit: rev 2017 - trunk/subversion/libsvn_subr References: From: Philip Martin Date: 28 May 2002 14:28:08 +0100 In-Reply-To: Message-ID: <87it58z9jr.fsf@codematters.co.uk> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Philip Martin X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Sander Striker" 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