"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.
Do any developers regularly build/test using --enable-dso? Has anyone
ever done any stress testing with --enable-dso?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 31 20:11:39 2006