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
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 21420)]
0x4026f09b in iconv_close () from /lib/libc.so.6
(gdb) where
#0 0x4026f09b in iconv_close () from /lib/libc.so.6
#1 0x4026e8e8 in iconv () from /lib/libc.so.6
#2 0x401694c8 in apr_xlate_conv_buffer (convset=0x8080948,
inbuf=0x8098d78 "working_copies/basic_tests-11/A/D/H/.svn/log",
inbytes_left=0xbffff480, outbuf=0x8098dc0 "", outbytes_left=0xbffff47c)
at xlate.c:391
#3 0x4014ea15 in convert_to_stringbuf (convset=0x8080948,
src_data=0x8098d78 "working_copies/basic_tests-11/A/D/H/.svn/log",
src_length=44, dest=0xbffff4d8, pool=0x8080780)
at subversion/libsvn_subr/utf.c:154
#4 0x4014f172 in svn_utf_cstring_from_utf8 (dest=0xbffff510,
src=0x8098d78 "working_copies/basic_tests-11/A/D/H/.svn/log",
pool=0x8080780) at subversion/libsvn_subr/utf.c:375
#5 0x401434ca in svn_io_check_path (
path=0x8098d78 "working_copies/basic_tests-11/A/D/H/.svn/log",
kind=0xbffff598, pool=0x8080780) at subversion/libsvn_subr/io.c:69
#6 0x4003e6c4 in svn_wc__adm_is_cleanup_required (cleanup=0xbffff5d4,
adm_access=0x8080890, pool=0x8080780) at
subversion/libsvn_wc/lock.c:590
#7 0x4003d818 in pool_cleanup (p=0x8080890) at
subversion/libsvn_wc/lock.c:136
#8 0x401b1cab in run_cleanups (c=0x80809c0) at apr_pools.c:1964
#9 0x401b1078 in apr_pool_destroy (pool=0x8080780) at apr_pools.c:746
#10 0x401b105e in apr_pool_destroy (pool=0x805eac8) at apr_pools.c:743
#11 0x0804e9c3 in main (argc=3, argv=0xbffff914)
at subversion/clients/cmdline/main.c:833
#12 0x4026e14f in __libc_start_main () from /lib/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.)
Thanks,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 9 00:14:09 2002