You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/11/08 22:40:50 UTC
Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr
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
Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@apache.org> writes:
> No. r3701 is the correct solution. Nothing else makes any sense.
> What we had before was just blantantly wrong. The only thing I can
> think of is that there might be an iconv() library that isn't
> thread-safe and doesn't support multiple open buffers. But, that'd be
> a flaw in the iconv() implementation not the core iconv() API (as it
> worked on Darwin).
What happens is that the pool gets destroyed, the pool cleanup
handlers run, one of which is the apr_xlate_t handler which calls
iconv_close(). However the userdata still points to the apr_xlate_t.
A second, independent, pool cleanup handler then runs which attempts
to do a UTF8 conversion. This looks up the userdata and gets the
address of the apr_xlate_t object for which iconv_close has been
called.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, November 08, 2002 16:40:50 -0600 Karl Fogel
<kf...@newton.ch.collab.net> wrote:
> Hey Justin, did you run 'make check' on this?
Yeah, I waited for about an hour while the tests ran. So, it did pass all
tests with flying colors for me on Darwin. I wouldn't have checked it in
otherwise.
> 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:
Hmm. I'll try to reproduce this on Solaris, as I'm not near my Darwin box,
it'll take me a bit to get it up to where I can test it. (It's not
recognizing my libtool install right now.)
It's very possible that there are bad iconv() implementations flying around.
As I don't have a Linux box, I can't test with that iconv() implementation.
> 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.)
No. r3701 is the correct solution. Nothing else makes any sense. What we
had before was just blantantly wrong. The only thing I can think of is
that there might be an iconv() library that isn't thread-safe and doesn't
support multiple open buffers. But, that'd be a flaw in the iconv()
implementation not the core iconv() API (as it worked on Darwin).
Regardless, I'm trying to reproduce here. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Blair Zajac <bl...@orcaware.com> writes:
>I'm getting the exact same core dump on RedHat 8.0:
Bing! Thanks for the data point.
> I vote for a revert now while we find the fix for the problem.
Hmm. There's a problem if we revert, and a problem if we don't, it's
just that we happened not to have an automated test for the original
problem :-).
Here's the thread Philip started with his post about the original
problem:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=68474
Given the circumstances he described, yeah, the best course is
probably to revert. Not because there's anything wrong with 3701, but
because it reveals a latent bug that we don't yet have a fix for. We
should unrevert when we can deal with all the consequences. Not
ideal, but then again, the original problem isn't likely to show up
under most circumstances.
I'll revert, and file an issue. (Sigh, got just enough brainpower to
file issues right now; maybe tomorrow I'll have enough to actually do
something about it :-) ).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr
Posted by Blair Zajac <bl...@orcaware.com>.
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 <bl...@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