You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2007/08/31 17:21:16 UTC
Re: reproducible SERF crash
Heh, subject should be reproducible *serf* crash. :-)
On 8/31/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> I'm using serf (r1122) on OSX, and here's my recipe for a crash:
>
> 1. Checkout (or switch) to
> https://svn.collab.net/repos/svn/branches/copy-on-update
>
> 2. svn merge -r26233:HEAD https://svn.collab.net/repos/svn/trunk
>
>
> After ~400 files are merged, serf crashes when trying to clean up.
> Maybe a double-free sort of situation?
>
> U subversion/svn/commit-cmd.c
> U subversion/svn/propset-cmd.c
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at addp coress: 0x000e9120
> serf_connection_close (conn=0xdf018) at context.c:1036
>
> (gdb) where
> #0 serf_connection_close (conn=0xdf018) at context.c:1036
> #1 0x0053e19a in svn_ra_serf__cleanup_serf_session (data=0x100a0f0)
> at subversion/libsvn_ra_serf/util.c:143
> #2 0x00731a9e in run_cleanups (cref=0x1819828) at memory/unix/apr_pools.c:2034
> #3 0x0073241a in apr_pool_destroy (pool=0x1819818) at
> memory/unix/apr_pools.c:727
> #4 0x00732405 in apr_pool_destroy (pool=0x180b618) at
> memory/unix/apr_pools.c:724
> #5 0x0000cd23 in main (argc=4, argv=0xbffff650) at subversion/svn/main.c:1766
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reproducible SERF crash
Posted by Lieven Govaerts <sv...@mobsol.be>.
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
Re: reproducible SERF crash
Posted by Ben Collins-Sussman <su...@red-bean.com>.
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. :-)
On 8/31/07, Lieven Govaerts <sv...@mobsol.be> wrote:
> Ben,
>
> are you using svn trunk older than r26213?
>
> I already solved a similar segfault in r26213 (last week). It's probably
> not a serf issue, but an ra_serf issue as the connections are created
> and managed by ra_serf (through a wrapper object).
>
> Lieven
>
> Ben Collins-Sussman wrote:
> > Heh, subject should be reproducible *serf* crash. :-)
> >
> > On 8/31/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >
> >> I'm using serf (r1122) on OSX, and here's my recipe for a crash:
> >>
> >> 1. Checkout (or switch) to
> >> https://svn.collab.net/repos/svn/branches/copy-on-update
> >>
> >> 2. svn merge -r26233:HEAD https://svn.collab.net/repos/svn/trunk
> >>
> >>
> >> After ~400 files are merged, serf crashes when trying to clean up.
> >> Maybe a double-free sort of situation?
> >>
> >> U subversion/svn/commit-cmd.c
> >> U subversion/svn/propset-cmd.c
> >>
> >> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >> Reason: KERN_INVALID_ADDRESS at addp coress: 0x000e9120
> >> serf_connection_close (conn=0xdf018) at context.c:1036
> >>
> >> (gdb) where
> >> #0 serf_connection_close (conn=0xdf018) at context.c:1036
> >> #1 0x0053e19a in svn_ra_serf__cleanup_serf_session (data=0x100a0f0)
> >> at subversion/libsvn_ra_serf/util.c:143
> >> #2 0x00731a9e in run_cleanups (cref=0x1819828) at memory/unix/apr_pools.c:2034
> >> #3 0x0073241a in apr_pool_destroy (pool=0x1819818) at
> >> memory/unix/apr_pools.c:727
> >> #4 0x00732405 in apr_pool_destroy (pool=0x180b618) at
> >> memory/unix/apr_pools.c:724
> >> #5 0x0000cd23 in main (argc=4, argv=0xbffff650) at subversion/svn/main.c:1766
> >>
> >>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reproducible SERF crash
Posted by Lieven Govaerts <sv...@mobsol.be>.
Ben,
are you using svn trunk older than r26213?
I already solved a similar segfault in r26213 (last week). It's probably
not a serf issue, but an ra_serf issue as the connections are created
and managed by ra_serf (through a wrapper object).
Lieven
Ben Collins-Sussman wrote:
> Heh, subject should be reproducible *serf* crash. :-)
>
> On 8/31/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
>
>> I'm using serf (r1122) on OSX, and here's my recipe for a crash:
>>
>> 1. Checkout (or switch) to
>> https://svn.collab.net/repos/svn/branches/copy-on-update
>>
>> 2. svn merge -r26233:HEAD https://svn.collab.net/repos/svn/trunk
>>
>>
>> After ~400 files are merged, serf crashes when trying to clean up.
>> Maybe a double-free sort of situation?
>>
>> U subversion/svn/commit-cmd.c
>> U subversion/svn/propset-cmd.c
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at addp coress: 0x000e9120
>> serf_connection_close (conn=0xdf018) at context.c:1036
>>
>> (gdb) where
>> #0 serf_connection_close (conn=0xdf018) at context.c:1036
>> #1 0x0053e19a in svn_ra_serf__cleanup_serf_session (data=0x100a0f0)
>> at subversion/libsvn_ra_serf/util.c:143
>> #2 0x00731a9e in run_cleanups (cref=0x1819828) at memory/unix/apr_pools.c:2034
>> #3 0x0073241a in apr_pool_destroy (pool=0x1819818) at
>> memory/unix/apr_pools.c:727
>> #4 0x00732405 in apr_pool_destroy (pool=0x180b618) at
>> memory/unix/apr_pools.c:724
>> #5 0x0000cd23 in main (argc=4, argv=0xbffff650) at subversion/svn/main.c:1766
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org