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?
>
> Perhaps we should stop using a manifest constant, then. We've certainly
> chosen to allocate memory in a passed-in pool rather than use a manifest
> constant in some past situations, for just this reason.
>
> 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.
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.
>> So as a possibly more maintainable alternative, the hack below fixes
>> apr_dso_load() callers to always use tiny dedicated pools which are
>> never deallocated.
>
> Your patch isn't very thread-safe. We could use svn_ra_initialize() to
> set up the dedicated pool and a mutex protecting it, but because we
> introduced svn_ra_initialize() in 1.2, we can't require every client to
> call it.
>
> 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 :-(
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 27 20:20:39 2005