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

Re: Another 1.4 release critical bug

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-07-31 20:13:44 CEST

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.


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:15:28 2006

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.