--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.
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 -
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. =) -- justin
---------------------------------------------------------------------
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:41:27 2002