Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> I'm not sure what that BASE_URL option is. Since I use VPATH, I can't

BASE_URL= is the same as --url it runs the tests over ra_dav.

> run basic_tests.py directly (I don't know how to trick it to run in
> VPATH since it expects everything to be in srcdir). Is there a way to
> do the tests over ra_dav or something? Is that documented? Can I set
> that up with a VPATH build?

I use a VPATH build. Just cd subversion/tests/client/cmdline and
then /path/to/src/subversion/tests/clients/cmdline/basic_tests.py

> Oooh, even then, I have an idea what is going on. I bet that the
> pool_cleanup is passing down the same *destroyed* pool to
> svn_wc__adm_is_cleanup_required. That's a no-no. It looks we're
> trying to use a closed iconv() handle in that already/partially
> cleaned-up pool.

Yup, I think that's it. The access baton pool handler will do a UTF8
conversion.

> Cleanups can't assume that their pools are still valid and have
> anything in them (there is purposely no order to how cleanups in a
> pool are invoked -

Is that documented anywhere? We have cleanup handlers that do quite a
lot. It's always worked up to now. How else are you supposed to do
it? Is every application expected to maintain it's own cleanup
mechanism?

> this is to minimize what people do in a cleanup). So, the
> iconv_close() has already been called by its pool cleanup function
> (registered by apr_xlate). (Sander would know even more about the
> pool logic than I and could confirm my hunch.)
>
>
> The reason reverting the patch works is that the iconv buffer isn't
> coming from that pool, but instead from the global pool (which is
> never cleaned up). I bet that on Solaris and Darwin, the iconv()
> buffers are stateless (i.e. a close does nothing), or the pool_cleanup
> is called before the iconv_close cleanup.
>
>
> You can't have any dependencies between pool cleanups. Either that
> pool passed to svn_wc__adm_is_cleanup_required must be that pool's
> parent (perhaps easiest), or pool_cleanup must go away. Regardless,
> r3701 isn't at fault. It just indicated the faulty logic here. =)

Well, I don't see any documentation that describes these limitations.
It's not what I would expect of a cleanup system :-(

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org