Re: svnsync funniness with bdb repositories

Lieven Govaerts wrote:
> Hyrum K. Wright wrote:
>> Hyrum K. Wright wrote:
> ..
>> More weirdness with svnsync. In trying to sync the gcc repository, I get
>> consistent segfaults using a trunk build of svnsync. This is a transcript of
>> the session:
>> $ ~/dev/svn-trunk/subversion/svnsync/svnsync sync \
>> file:///home/hwright/test/gcc.bdb
>> Copied properties for revision 8132.
>> Transmitting file data
>> Committed revision 8133.
>> Segmentation fault (core dumped)
>> $ svnd pd --revprop -r 0 svn:sync-lock file:///home/hwright/test/gcc.bdb
>> property 'svn:sync-lock' deleted from repository revision 0
>> $ ~/dev/svn-trunk/subversion/svnsync/svnsync sync \
>> file:///home/hwright/test/gcc.bdb
>> Copied properties for revision 8133.
>> Transmitting file data
>> Committed revision 8134.
>> Segmentation fault (core dumped)
>> $ svnd pd --revprop -r 0 svn:sync-lock file:///home/hwright/test/gcc.bdb
>> property 'svn:sync-lock' deleted from repository revision 0
>> $ ~/dev/svn-trunk/subversion/svnsync/svnsync sync \
>> file:///home/hwright/test/gcc.bdb
>> Copied properties for revision 8134.
>> Transmitting file data
>> Committed revision 8135.
>> Segmentation fault (core dumped)
>>
>> It gets through one revision, and then crashes. It doesn't crash on *every*
>> revision, but for this repository in this case it is behaving that way. This is
>> a transcript of a gdb session.
>>
>> (gdb) r
>> [Thread debugging using libthread_db enabled]
>> [New Thread -1216358736 (LWP 30619)]
>> Copied properties for revision 8138.
>> Transmitting file data
>> Committed revision 8139.
>>
> ..
>
> Do you have the same issue with fsfs? I starting syncing the gcc
> repository over svn to a local fsfs repository, but the first 100
> revisions or so sync without problem.

I haven't tried that yet. I'll let you know what (if anything) I come
up with.

> I don't see anything special about the revisions, besides the fact that
> the svn:author revprop isn't set, but that shouldn't be a problem.
> Seeing that after you restart svnsync it manages to correctly copy the
> revision properties I assume it's a local bug in the new svnsync
> callback code.

Possibly. I've noticed that all the revisions where I'm getting
segfaults don't have the svn:author revprop set. (Also, see the test
failure below.)

> Can you successfully run the svnsync tests over svn with a bdb repository?

No. I get an failure in test 19:

EXCEPTION: SVNUnexpectedStderr: ['subversion/libsvn_repos/hooks.c:228:
(apr_err=165001)\n', "svnsync: Failed to start
'/home/hwright/dev/svn-apache/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-19-1/hooks/pre-revprop-change'
hook\n", 'subversion/libsvn_subr/utf.c:632: (apr_err=22)\n', 'svnsync:
Valid UTF-8 data\n', '(hex: 18)\n', 'followed by invalid UTF-8
sequence\n', '(hex: fd 09 08)\n']
Traceback (most recent call last):
  File
"/home/hwright/dev/svn-apache/subversion/tests/cmdline/svntest/main.py",
line 1059, in run
    rc = apply(self.pred.run, (), kw)
  File
"/home/hwright/dev/svn-apache/subversion/tests/cmdline/svntest/testcase.py",
line 121, in run
    return self.func(sandbox)
  File "./svnsync_tests.py", line 638, in no_author
    run_test(sbox, "no-author.dump")
  File "./svnsync_tests.py", line 114, in run_test
    run_sync(dest_sbox.repo_url)
  File "./svnsync_tests.py", line 56, in run_sync
    raise SVNUnexpectedStderr(errput)
SVNUnexpectedStderr: ['subversion/libsvn_repos/hooks.c:228:
(apr_err=165001)\n', "svnsync: Failed to start
'/home/hwright/dev/svn-apache/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-19-1/hooks/pre-revprop-change'
hook\n", 'subversion/libsvn_subr/utf.c:632: (apr_err=22)\n', 'svnsync:
Valid UTF-8 data\n', '(hex: 18)\n', 'followed by invalid UTF-8
sequence\n', '(hex: fd 09 08)\n']
FAIL: svnsync_tests.py 19: test copying revs with no svn:author revprops

>> This is the point that I get lost, not having any experience with svnsync.
>> Could somebody with more knowledge take a look? Would it be better filed as an
>> issue in the the bug tracker?
>>
> The faulty code was all rewritten on trunk, still, better to create an
> issue for 1.5 so we don't forget. I'll have a look once I have more time
> (this weekend at the latest). I tried to get a bdb build on my ubuntu
> laptop, but that seemed to be a problem (keeps complaining apr-util
> isn't linked with bdb).

You've just hit Ubuntu bug #96980 [1]. I have a custom apr build
sitting in /usr/local/ which I use to work around this issue.

[1] https://bugs.launchpad.net/ubuntu/+source/apr-util/+bug/96980

Thanks for the help,
-Hyrum