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
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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jul 27 23:39:39 2005