Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <483B3A9B.5010205@xbc.nu>
Date: Tue, 27 May 2008 00:32:59 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: David Glasser <glasser@davidglasser.net>
CC: Martin von Gagern <Martin.vGagern@gmx.net>, dev@apr.apache.org,
 dev@subversion.tigris.org
Subject: Re: apr cleanup unloads neon library too soon in git-svn
References: <483B3084.9000806@gmx.net>
 <1ea387f60805261521t5fc3094eh1578e7dbae1d48c2@mail.gmail.com>
In-Reply-To: <1ea387f60805261521t5fc3094eh1578e7dbae1d48c2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

David Glasser wrote:
> On Mon, May 26, 2008 at 2:49 PM, Martin von Gagern
> <Martin.vGagern@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