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
On 8/31/07, Lieven Govaerts <email@example.com> wrote:
> 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).
> Ben Collins-Sussman wrote:
> > Heh, subject should be reproducible *serf* crash. :-)
> > On 8/31/07, Ben Collins-Sussman <firstname.lastname@example.org> 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Aug 31 20:06:17 2007