> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: 09 November 2002 01:40
> --On Friday, November 08, 2002 16:45:46 -0600 Karl Fogel
> <kfogel@newton.ch.collab.net> wrote:
>
> > meant -- it's quite possible that this sort of thing would pass make
> > check on some systems yet fail on others. The real question was:
> > Justin, can you reproduce this, and if not, does my stack trace help
> > identify the cause anyway?
>
> Nope, I can't reproduce on Solaris, either. Well, that is that 'make
> check' passes for basic_tests.py (up to prop_tests.py with success).
>
> I'm not sure what that BASE_URL option is. Since I use VPATH, I can't 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?
>
> 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.
You should never use a pool after calling apr_pool_destroy or apr_pool_clear.
Cleanups should not use the pool they are cleaning up in for new allocations
or other operations.
> Cleanups can't assume that their pools are still valid and have anything in
> them
correct.
> (there is purposely no order to how cleanups in a pool are invoked -
Last in, first out.
> 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.
That are the options that came to my mind aswell.
> Regardless, r3701 isn't at fault. It just indicated the faulty logic here.
> =) -- justin
I agree.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 9 01:53:44 2002