Hyrum K. Wright wrote:
> Ran across this little beauty while trying to set up a mirror of the gcc
> repository. (Using the 1.4.x branch)
>
> $ svnadmin create gcc.bdb --fs-type bdb
> $ cat <<'EOF' > gcc.bdb/hooks/pre-revprop-change
>> #!/bin/sh
>> exit 0
>> EOF
> $ chmod +x gcc.bdb/hooks/pre-revprop-change
> $ svnsync init file://`pwd`/gcc.bdb/ svn://gcc.gnu.org/svn/gcc/
> Segmentation fault (core dumped)
>
> So, I tried it with FSFS:
>
> $ svnadmin create gcc.fsfs
> $ cat <<'EOF' > gcc.fsfs/hooks/pre-revprop-change
>> #!/bin/sh
>> exit 0
>> EOF
> $ chmod +x gcc.fsfs/hooks/pre-revprop-change
> $ svnsync init file://`pwd`/gcc.fsfs/ svn://gcc.gnu.org/svn/gcc/
> Copied properties for revision 0.
>
> And it works! When I try with a recent trunk build, with
> --enable-maintainer-mode, I get the following results with a bdb repository:
>
> $ svnadmin create gcc.bdb --fs-type bdb
> $ cat <<'EOF' > gcc.bdb/hooks/pre-revprop-change> #!/bin/sh
>> exit 0
>> EOF
> $ chmod +x gcc.bdb/hooks/pre-revprop-change
> $ ~/dev/svn-trunk/subversion/svnsync/svnsync init file://`pwd`/gcc.bdb/
> svn://gcc.gnu.org/svn/gcc/
> subversion/libsvn_fs_base/err.c:60: (apr_err=160006)
> svnsync: Reference to non-existent revision 0 in filesystem
> '/home/hwright/test/gcc.bdb/db'
>
> But, when I create the repo with a trunk build, and then try it, it works:
>
> $ ~/dev/svn-trunk/subversion/svnadmin/svnadmin create gcc.bdb --fs-type bdb
> $ cat <<'EOF' > gcc.bdb/hooks/pre-revprop-change
>> #!/bin/sh
>> exit 0
>> EOF
> $ chmod +x gcc.bdb/hooks/pre-revprop-change
> $ ~/dev/svn-trunk/subversion/svnsync/svnsync init file://`pwd`/gcc.bdb/
> svn://gcc.gnu.org/svn/gcc/
> Copied properties for revision 0.
>
> So, it works when using a trunk-created svnadmin, and a trunk-created
> svnsync. But, if the repo was created with 1.4.x, the sync won't be
> initialized for bdb repositories. Was there a bug fixed in trunk
> regarding creation of bdb repositories? Should that fix be backported?
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.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216358736 (LWP 30619)]
apr_hash_next (hi=0x8199330) at tables/apr_hash.c:130
/home/hwright/dev/apr-1.2.12/tables/apr_hash.c:130:3539:beg:0xb7d9fb8f
(gdb) p hi
$1 = (apr_hash_index_t *) 0x8199330
(gdb) p hi->this
$2 = (apr_hash_entry_t *) 0x77682f65
(gdb) p hi->next
$3 = (apr_hash_entry_t *) 0x0
(gdb) p hi->this->next
Cannot access memory at address 0x77682f65
(gdb) backtrace
#0 apr_hash_next (hi=0x8199330) at tables/apr_hash.c:130
#1 0x0804e1d7 in remove_props_not_in_source (session=0x8153248, rev=8139,
source_props=0x818ea78, target_props=0x81d1428, pool=0x818e690) at
subversion/svnsync/main.c:362
#2 0x0804fc11 in replay_rev_finished (revision=8139, replay_baton=0x818d880,
editor=0x8198af0, edit_baton=0x8198b30, rev_props=0x818ea78, pool=0x818e690) at
subversion/svnsync/main.c:1305
#3 0x0805347e in svn_ra_replay_range (session=0x8156238, start_revision=8139,
end_revision=131585, low_water_mark=0, text_deltas=1, revstart_func=0x804f8a7
<replay_rev_started>, revfinish_func=0x804fa8b <replay_rev_finished>,
replay_baton=0x818d880, pool=0x8143170) at subversion/libsvn_ra/ra_loader.c:1203
#4 0x080500f4 in do_synchronize (to_session=0x8153248, b=0x8153180,
pool=0x8143170) at subversion/svnsync/main.c:1455
#5 0x0804df68 in with_locked (session=0x8153248, func=0x804fd27
<do_synchronize>, baton=0x8153180, pool=0x8143170) at subversion/svnsync/main.c:284
#6 0x0805032a in synchronize_cmd (os=0x8143288, b=0xbfdade5c, pool=0x8143170)
at subversion/svnsync/main.c:1494
#7 0x080513dc in main (argc=3, argv=0xbfdadf84) at subversion/svnsync/main.c:1967
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?
-Hyrum
Received on 2008-01-18 00:13:54 CET