[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: stack trace for merge problem (ra_serf)

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Thu, 18 Sep 2008 04:09:49 +0200

Greg Stein wrote:
> Lieven, et al,
>
> I attempted the following merge in the root of the explore-wc branch:
>
> $ svn merge https://svn.collab.net/repos/svn/trunk
>
> and it generated a core dump with the following traceback:
>
> #0 0x96c2fb9e in kill$UNIX2003 ()
> #1 0x96ca6ec2 in raise ()
> #2 0x96cb647f in abort ()
> #3 0x001ca8cd in serf_bucket_mem_free ()
> #4 0x001c822c in serf_default_destroy_and_data ()
..
No line numbers, but I assume this is a DOUBLE FREE abort.

> subversion/libsvn_ra_serf/getlocationsegments.c:218
> #16 0x000f4d7b in svn_ra_get_location_segments (session=0x81f890,
> path=0x8b6a18 "build.conf", peg_revision=33146, start_rev=33146,
> end_rev=1, receiver=0x8006a <gls_receiver>, receiver_baton=0xbfffe990,
> pool=0x81f418) at subversion/libsvn_ra/ra_loader.c:1198
..

I have seen this stacktrace a few times myself. You've encountered issue
 #3212. The issue is that ra_serf is reusing buckets when resending a
request. I'm not sure why the request needs to be resent, but that
happens from time to time.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-18 04:09:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.