Karl Fogel wrote:
>
> jerenkrantz@tigris.org writes:
> > Author: jerenkrantz
> > Date: 2002-11-08 13:29:34 -0600 (Fri, 08 Nov 2002)
> > New Revision: 3701
> >
> > Modified:
> > trunk/subversion/libsvn_subr/utf.c
> > Log:
> > * subversion/libsvn_subr/utf.c (get_ntou_xlate_handle,
> > get_uton_xlate_handle): No longer walk up the tree looking for
> > global_pool, but rather just use the passed-in pool.
>
> Hey Justin, did you run 'make check' on this?
>
> This test
>
> $ cd subversion/tests/clients/cmdline
> $ ./basic_tests 11 BASE_URL=http://localhost
>
> seems to be failing now. In the Python, this call to 'svn rm' seg
> faults:
>
> # 'svn rm' that should fail
> stdout_lines, stderr_lines = svntest.main.run_svn(1, 'rm', chi_path)
> if len (stderr_lines) == 0:
> return 1
>
> (The comment above is in the code, I didn't add it). Clearly the
> command is expected to fail, but probably not with a segmentation
> fault leaving the working copy in a locked state. :-)
>
> The seg fault happens in iconv_close():
>
> (gdb) run rm working_copies/basic_tests-11/A/D/H/chi
> Starting program:
> /home/kfogel/src/subversion/subversion/clients/cmdline/.libs/lt-svn rm
> working_copies/basic_tests-11/A/D/H/chi
> [New Thread 1024 (LWP 21420)]
> subversion/clients/cmdline/delete-cmd.c:47: (apr_err=195006, src_err=0)
> svn: Attempting restricted operation for modified resource
> svn: Use --force to override this restriction
> subversion/libsvn_client/delete.c:91: (apr_err=195006, src_err=0)
> svn: 'working_copies/basic_tests-11/A/D/H/chi' has local modifications
I'm getting the exact same core dump on RedHat 8.0:
#0 0x42016aa2 in __gconv () from /lib/i686/libc.so.6
#1 0x4201618d in iconv () from /lib/i686/libc.so.6
#2 0x401cb876 in apr_xlate_conv_buffer (convset=0x8072090,
inbuf=0x808a818 "working_copies/basic_tests-11/A/D/H/.svn/log",
inbytes_left=0xbfffeeb8, outbuf=0xbfffee38 "", outbytes_left=0xbfffeeb4)
at xlate.c:391
#3 0x401aea0a in convert_to_stringbuf (convset=0x8072090,
src_data=0x808a818 "working_copies/basic_tests-11/A/D/H/.svn/log",
src_length=44, dest=0xbfffeee4, pool=0x8071ec8)
at subversion/libsvn_subr/utf.c:154
#4 0x401aef90 in svn_utf_cstring_from_utf8 (dest=0xbfffef2c,
src=0x808a818 "working_copies/basic_tests-11/A/D/H/.svn/log",
pool=0x8071ec8) at subversion/libsvn_subr/utf.c:376
#5 0x401a5461 in svn_io_check_path (path=0x8072090 "È\036\a\b¸ \a\b¨ \a\b",
kind=0xbfffefcc, pool=0x8071ec8) at subversion/libsvn_subr/io.c:69
#6 0x4003855e in svn_wc__adm_is_cleanup_required (cleanup=0x293a3e74,
adm_access=0x293a3e74, pool=0x8072090) at subversion/libsvn_wc/lock.c:590
#7 0x400378f0 in pool_cleanup (p=0x8072090) at subversion/libsvn_wc/lock.c:136
#8 0x4020f689 in run_cleanups (c=0x8072090) at apr_pools.c:1964
#9 0x4020eddd in apr_pool_destroy (pool=0x8071ec8) at apr_pools.c:746
#10 0x4020ee98 in apr_pool_destroy (pool=0x805d2a0) at apr_pools.c:743
#11 0x0804d8a5 in main (argc=0, argv=0x293a3e74)
at subversion/clients/cmdline/main.c:788
#12 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
> When I run the test with revision 3701 reverted, it passes (no seg
> fault).
>
> Do you think we should revert 3701 while we find a different fix for
> the original problem 3701 was meant to solve, or is the Right Solution
> here immediately obvious to you? (It's not to me, but then, it's been
> a while since I looked at the i18n code.)
I vote for a revert now while we find the fix for the problem.
Best,
Blair
--
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 9 04:02:50 2002