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

Re: [PATCH] RA sessions should always be loaded from the same pool

From: Nix <nix_at_esperi.org.uk>
Date: 2005-07-27 20:59:38 CEST

On Wed, 27 Jul 2005, Philip Martin announced authoritatively:
> Greg Hudson <ghudson@MIT.EDU> writes:
>> On Wed, 2005-07-27 at 17:34 +0100, Nix wrote:
>>> The cause of this is that a key in the auth_baton hash has been
>>> invalidated and points at a no-longer-valid address. How, you might ask,
>>> since all the keys are manifest constants?
>> Can you say more about where these constants are coming from?
> I think Nix is referring to constants like SVN_AUTH_PARAM_CONFIG, each
> DSO most likely has it's own copy.

Indeed; since they're string constants in shared libraries, saving a
precognitive linker or an astonishingly powerful dynamic loader, each
DSO certainly will get its own copy. Which will vanish when that DSO's

> The stack trace is a bit odd, it shows svn_ra_dav__open calling
> apr_hash_set directly, but in the source code svn_ra_dav__open calls
> svn_auth_set_parameter which in turn calls apr_hash_set.

That's not unusual: GCC has inlined the one-line
svn_auth_set_parameter() into its caller.

>> More importantly, it should be possible to dynamically load the
>> Subversion client library and then unload it without leaving big
>> footprints behind. So, we should get our memory management story right,
>> rather than applying a big hammer to the DSO system.
> The DSO will get unloaded when the pool used to load it is
> cleared/destroyed. Does the parameters hash persist longer than the
> DSO? That doesn't sound right to me, but then the auth stuff has so
> many layers I gave up trying to follow it some time ago :-(

It feels wrong to me, too, but it appears to outlast the pool used by
the RA *loader*, which (from experiment ;) ) may not be the same pool.

> I don't think --enable-dso gets much testing during development, the
> build broke in the run up to 1.2 and it took longer than usual to get
> noticed.

Well, I never build without it, so if there's blatant breakage I'll
let you know :)

`Tor employs several thousand editors who they keep in dank
 subterranean editing facilities not unlike Moria' -- James Nicoll 
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 27 23:39:39 2005

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.