Eric Gillespie wrote:
> Stupid gmail is still flagging some mails from google.com as
> phishing/spam. Sigh. Maybe this will help folks see it.
>
I use Thunderbird which doesn't block you (yet ;)).
> epg_at_google.com writes:
>
>
>> Not a release blocker of course; serf's experimental. In my
>> 1.5.x branch working copy:
>>
>> 0 1.5.x% svnversion
>> 31660:31696
>>
>> Entire wc is at 31660, except STATUS at 31696. Sometimes it
>> crashes, sometimes it doesn't.
>>
>> 1 1.5.x% svn cleanup; svn revert -R .
>> Reverted 'subversion/include/svn_io.h'
>> Reverted 'subversion/libsvn_client/diff.c'
>> 0 1.5.x% svn merge -c r31685 http://svn.collab.net/repos/svn/trunk
>> --- Merging r31685 into '.':
>> U subversion/include/svn_io.h
>> U subversion/libsvn_client/diff.c
>> 0 1.5.x% svn cleanup; svn revert -R .
>> Reverted '.'
>> Reverted 'COMMITTERS'
>> Reverted 'subversion/include/svn_io.h'
>> Reverted 'subversion/libsvn_client/diff.c'
>> Reverted 'subversion/bindings/swig'
>> Reverted 'CHANGES'
>> 0 1.5.x% svn merge -c r31685 http://svn.collab.net/repos/svn/trunk
>> --- Merging r31685 into '.':
>> U subversion/include/svn_io.h
>> U subversion/libsvn_client/diff.c
>> zsh: segmentation fault (core dumped) svn merge -c r31685 http://svn.collab.net/repos/svn/trunk
>>
>> (gdb) bt
>> #0 0x47d04203 in strncmp () from /lib/tls/i686/cmov/libc.so.6
>> #1 0xf7e56024 in svn_path_is_ancestor (
>> path1=0x81e6fe8 "http://svn.collab.net/repos/svn",
>> path2=0x194 <Address 0x194 out of bounds>)
>> at subversion/libsvn_subr/path.c:689
>> #2 0xf7f76475 in svn_ra_reparent (session=0x80b3dd8,
>> url=0x194 <Address 0x194 out of bounds>, pool=0x81e6b78)
>> at subversion/libsvn_ra/ra_loader.c:538
>> #3 0xf7fe7367 in do_directory_merge (
>> url1=0x8192ba8 "http://svn.collab.net/repos/svn/trunk", revision1=31684,
>> url2=0x8192bf0 "http://svn.collab.net/repos/svn/trunk", revision2=31685,
>> parent_entry=0x80b11b0, adm_access=0x80b1118, depth=svn_depth_infinity,
>> notify_b=0xffffcf10, merge_b=0xffffcf40, pool=0x80b3840)
>> at subversion/libsvn_client/merge.c:4352
>> #4 0xf7fe80ef in do_merge (merge_sources=0x8191b58, target=0x806e1a0 "",
>> target_entry=0x80b11b0, adm_access=0x80b1118, sources_ancestral=1,
>> sources_related=1, same_repos=1, ignore_ancestry=0, force=0, dry_run=0,
>> record_only=0, depth=svn_depth_infinity, merge_options=0x0, ctx=0x807c990,
>> pool=0x807c128) at subversion/libsvn_client/merge.c:4772
>> #5 0xf7fea2ec in svn_client_merge_peg3 (
>> source=0x80b0fb0 "http://svn.collab.net/repos/svn/trunk",
>> ranges_to_merge=0x807c2a8, peg_revision=0xffffd094,
>> target_wcpath=0x806e1a0 "", depth=svn_depth_unknown, ignore_ancestry=0,
>> force=0, record_only=0, dry_run=0, merge_options=0x0, ctx=0x807c990,
>> pool=0x807c128) at subversion/libsvn_client/merge.c:5716
>> #6 0x08056771 in svn_cl__merge (os=0x807c2c8, baton=0xffffd19c,
>> pool=0x807c128) at subversion/svn/merge-cmd.c:307
>> #7 0x08055e53 in main (argc=5, argv=0xffffd364) at subversion/svn/main.c:2018
>>
I've never had the error you're seeing before, but it looks like:
a) an issue in the pool usage, where the new repo root created by
reparent is allocated on the session pool, not on the pool passed into
the function.
b) an issue in the finish_report call.
While the stack trace and the value of the url in the reparent call
point me to a pool issue, I don't see a clear root cause.
OTOH, we have at least one open issue where svn aborts during merge in finish_report, and last weekend I've encountered a second abort. This leads me to believe that there's something seriously broken in that function.
I'm investigating a related stack trace and network trace which I hope leads me to the fix for the issue. In the meantime, can you log this in the issue tracker?
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-06-12 23:58:27 CEST