Nick Hengeveld <nickh_at_github.com> writes:
> It was a bug related to tag versions, and we just deployed a fix. I was
> able to do a checkout with a 1.7 client, let me know if you have any
> problems.
Oooh! Nasty client crash:
A wc/tags/v0.3/3rdParty/xunit/xunit.extensions.xml
A wc/tags/v0.3/3rdParty/xunit/xunit.gui.clr4.exe
*** glibc detected *** /home/pm/sw/subversion/obj/subversion/svn/.libs/lt-svn: corrupted double-linked list: 0x0000000001efb360 ***
======= Backtrace: =========
/lib/libc.so.6(+0x71bd6)[0x7facf7254bd6]
/lib/libc.so.6(+0x736a0)[0x7facf72566a0]
/lib/libc.so.6(cfree+0x6c)[0x7facf725994c]
/usr/local/httpd-2.2/lib/libapr-1.so.0(+0x1abb9)[0x7facf79a4bb9]
/usr/local/httpd-2.2/lib/libapr-1.so.0(+0x1acfe)[0x7facf79a4cfe]
/home/pm/sw/subversion/obj/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0(+0x1182e)[0x7facf828282e]
valgrind shows:
A wc/tags/v0.1/3rdParty/xunit/xunit.extensions.dll
A wc/tags/v0.1/3rdParty/xunit/xunit.extensions.xml
==3089== Invalid write of size 1
==3089== at 0x5A16FC1: decode_line (svn_base64.c:384)
==3089== by 0x5A17079: decode_bytes (svn_base64.c:421)
==3089== by 0x5A1721C: decode_data (svn_base64.c:465)
==3089== by 0x5A0F316: svn_stream_write (stream.c:161)
==3089== by 0x70BE98A: cdata_handler (fetch.c:1974)
==3089== by 0x70D22CF: wrapper_cdata_cb (util.c:1116)
==3089== by 0x60AB5FB: ??? (in /usr/lib/libneon.so.27.2.3)
==3089== by 0x95C14AE: xmlParseCharData (in /usr/lib/libxml2.so.2.7.8)
==3089== by 0x95CBC34: ??? (in /usr/lib/libxml2.so.2.7.8)
==3089== by 0x95CC30A: xmlParseChunk (in /usr/lib/libxml2.so.2.7.8)
==3089== by 0x60AB75E: ne_xml_parse (in /usr/lib/libneon.so.27.2.3)
==3089== by 0x70D286E: cancellation_callback (util.c:1241)
==3089== Address 0xbff3700 is 0 bytes after a block of size 3,936 alloc'd
==3089== at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==3089== by 0x5E7C130: pool_alloc (apr_pools.c:1463)
==3089== by 0x5A17851: my__realloc (svn_string.c:55)
==3089== by 0x5A18262: svn_stringbuf_ensure (svn_string.c:468)
==3089== by 0x5A17049: decode_bytes (svn_base64.c:413)
==3089== by 0x5A1721C: decode_data (svn_base64.c:465)
==3089== by 0x5A0F316: svn_stream_write (stream.c:161)
==3089== by 0x70BE98A: cdata_handler (fetch.c:1974)
==3089== by 0x70D22CF: wrapper_cdata_cb (util.c:1116)
==3089== by 0x60AB5FB: ??? (in /usr/lib/libneon.so.27.2.3)
==3089== by 0x95C14AE: xmlParseCharData (in /usr/lib/libxml2.so.2.7.8)
==3089== by 0x95CBC34: ??? (in /usr/lib/libxml2.so.2.7.8)
This solves the problem:
Index: ../src/subversion/libsvn_subr/svn_base64.c
===================================================================
--- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
+++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
@@ -410,7 +410,7 @@
/* Resize the stringbuf to make room for the (approximate) size of
output, to avoid repeated resizes later.
The optimizations in decode_line rely on no resizes being necessary! */
- svn_stringbuf_ensure(str, str->len + (len / 4) * 3 + 3);
+ svn_stringbuf_ensure(str, str->len + (len / 4) * 3 + 4);
while ( !*done && p < end )
{
but I don't really understand the comment. There doesn't seem to be
anything "approximate" about this calculation?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-09 01:05:30 CET