Ben Collins-Sussman wrote:
> I am using today's trunk client. Try reproducing it yourself.
>
> However, I need to ammend my reproduction recipe: when you do the
> initial checkout of my branch, be sure to checkout branchURL@26405 --
> because I've now merged the trunk to it successfully using neon in
> r26406. :-)
>
>
I didn't even get as far as you do on Windows:
c:\> svn co
http://svn.collab.net/repos/svn/branches/copy-on-update@26405 cou
..
c:\> svn merge -r26233:HEAD http://svn.collab.net/repos/svn/trunk
c:\temp\bug\cou
First run, it almost aborts immediately with a DEBUG_DOUBLE_FREE error.
That is caused by handling the 501 error code resulting from the
collab.net server not being mergeinfo aware. I patched this on my local
serf and sent the patch to serf-dev this morning for review.
Second run I get a bit further. First, I get a merge conflict - which
you didn't mention but I presume it's expected:
..
Conflict discovered in
'C:/temp/bug/cou/subversion/libsvn_wc/update_editor.c'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp : p
Then I get a stacktrace somewhere in the svn_subr__win32_xlate_to_stringbuf:
libapr.dll!apr_palloc(apr_pool_t * pool=0x00000001, unsigned int
size=8) Line 610 + 0x3 bytes C
libapr.dll!apr_palloc_debug(apr_pool_t * pool=0x00000001, unsigned
int size=1, const char * file_line=0x00670810) Line 2135 C
> svn.exe!svn_stringbuf_ncreate(const char * bytes=0x006c74af,
unsigned int size=0, apr_pool_t * pool=0x00000001) Line 241 + 0x16
bytes C
svn.exe!svn_stringbuf_create(const char * cstring=0x006c74af,
apr_pool_t * pool=0x00000001) Line 257 + 0x1a bytes C
svn.exe!svn_subr__win32_xlate_to_stringbuf(win32_xlate_t *
handle=0x00c12198, const char * src_data=0x00c1a1c0, unsigned int
src_length=0, svn_stringbuf_t * * dest=0x0012fbf4, apr_pool_t *
pool=0x00000001) Line 167 + 0xe bytes C
svn.exe!convert_to_stringbuf(xlate_handle_node_t * node=0x00c121a0,
const char * src_data=0x00c1a1c0, unsigned int src_length=0,
svn_stringbuf_t * * dest=0x0012fbf4, apr_pool_t * pool=0x00000001) Line
464 + 0x1b bytes C
svn.exe!convert_cstring(const char * * dest=0x0012fc38, const char
* src=0x00c1a1c0, xlate_handle_node_t * node=0x00c121a0, apr_pool_t *
pool=0x00000001) Line 741 + 0x22 bytes C
svn.exe!svn_utf_cstring_to_utf8(const char * * dest=0x0012fc38,
const char * src=0x00c1a1c0, apr_pool_t * pool=0x00000001) Line 763 +
0x15 bytes C
svn.exe!print_error(svn_error_t * err=0x00c1a1a8, _iobuf *
stream=0x10311d40, const char * prefix=0x0066266c) Line 315 + 0x23
bytes C
svn.exe!svn_handle_error2(svn_error_t * err=0x00c1a1a8, _iobuf *
stream=0x10311d40, int fatal=0, const char * prefix=0x0066266c) Line
405 + 0x11 bytes C
svn.exe!main(int argc=5, const char * * argv=0x003f5b10) Line 1740
+ 0x1d bytes C
svn.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
svn.exe!mainCRTStartup() Line 414 C
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
So it looks like there was an error, but the memory used to store the
error message was corrupted (pool=0x00000001). I presume we can still
trust the line number of the error - 2607 - being correct. The only
source file I could find with an error on line 2607 is io.c:
if (status)
return svn_error_wrap_apr(status, _("Can't open file '%s'"),
svn_path_local_style(fname, pool));
I didn't get to the bottom of this issue yet, but it's reproducible -
after 15 minutes. Note that such memory corruptions aren't new in
ra_serf, until now they've all been caused by using the wrong pool
during memory allocation.
I do have a local patch for the ra_serf-auth branch which fixes such an
issue, I'll see if that fixes this too.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 1 10:27:01 2007