Garrett Rooney wrote:
> On 7/31/06, Philip Martin <philip@codematters.co.uk> wrote:
>> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
>>
>> > On 7/31/06, Philip Martin <philip@codematters.co.uk> wrote:
>> >> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
>> >>
>> >> > I'm now able to run basic_tests.py over svnserve with a bdb 4.4
>> repos
>> >> > with apr built with pool debugging and under valgrind with no
>> errors,
>> >> > so I think we're on the right track ;-)
>> >>
>> >> Unfortunately it doesn't work with --enable-dso which is how some
>> >> (most?) distributions build Subversion. I think the problem is that
>> >> the callbacks happen after the DSO has been unloaded and so the
>> >> callback code is no longer part of the executable. Using trunk:
>> >
>> > *sob*
>> >
>> > I'll look into this later today, although honestly I'm kind of running
>> > out of ideas on this one...
>>
>> The loader code is scary! Take svn_fs_open for example, it calls
>> apr_dso_load passing the pool given to svn_fs_open. That means APR
>> will install a pool cleanup to unload the DSO when the svn_fs_open
>> pool is cleared. While the DSO is loaded if a second thread calls
>> svn_fs_open with a second pool it will expect the DSO to remain loaded
>> for the lifetime of the second pool which could exceed that of the
>> first pool; I guess we are relying on the OS both to merge and
>> refcount the dlopens.
>>
>> How about using a global pool when calling apr_dso_load? If we could
>> arrange for this to be the same pool that is used for the bdb env
>> cache then it should be possible to get things ordered correctly.
>
> Yeah, I've been thinking about stuff like that as likely solutions.
>
>> Do any developers regularly build/test using --enable-dso? Has anyone
>> ever done any stress testing with --enable-dso?
>
> Personally, I've never done so, I don't know if anyone else does.
Since we're not actually testing that stuff, and it seems to be a huge
potential problem, why don't we just disable DSO in 1.4? I think it's a
misfeature the way it's implemented now, anyway.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 1 00:36:13 2006