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

Re: apr cleanup unloads neon library too soon in git-svn

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 26 May 2008 15:21:48 -0700

On Mon, May 26, 2008 at 2:49 PM, Martin von Gagern
<Martin.vGagern_at_gmx.net> wrote:
> Hi!
>
> For the full details and several stack traces, please refer to
> https://bugs.gentoo.org/show_bug.cgi?id=223747
>
> The problem is that in some cases (running git-svn) when the APR cleanup
> (apr_terminate) cleans its pools (apr_pool_destroy), it will unload shared
> libraries (libsvn_ra_neon-1.so.0) while there are still neon objects around.
> When the cleanup tries to clean those, their cleanup function
> (cleanup_session) is no longer available, which causes a segmentation fault.
>
> I see two possible solutions. One is to have the APR cleanup code ensure
> that libraries get unloaded only after all other objects from the current
> part of the pool hierarchy have been cleaned. The other would be to have
> subversion pool management restructured in some way, such that the DSO pool
> gets cleared after the other objects.
>
> As I don't know which solution would be the better one, I post to both
> lists, APR and Subversion. Please also have a look at the corresponding
> discussion on the other list. I'll try to attach links to the threads in
> both mail archives to the Gentoo bug report stated above. Stay tuned.

Could we maybe make all of our "global" pools be children of the
DSO-managing pool?

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-27 00:22:11 CEST

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.