David Glasser wrote:
> 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?
>
That would imply having a global pool for all DSO stuff, which means
we'd need a process-global pool context for all SVN libraries. We don't
have the init API for that, and even if we did, we couldn't make its use
mandatory before 2.0.
This is a well-known gotcha in APR pool/DSO combinations, which only
really work in an httpd-like architecture where DSO loading is strictly
hierarchical. IMHO you can only be truly solved if you can create truly
global pools that aren't children of the "one true" global APR pool.
Which, I believe, is going to happen in apr-1.3; so /maybe/ our
DSO-loading code should try to detect, possibly at runtime, if that
feature exists, and use it.
-- Brane
---------------------------------------------------------------------
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:33:33 CEST