Your message dated Tue, 17 Dec 2019 22:06:07 -0500
with message-id <20191218030607.txhxwrf7aftolor3@localhost>
and subject line Re: Bug#425036: /usr/bin/svnadmin: attempted recovery leads to
segfault
has caused the Debian Bug report #425036,
regarding /usr/bin/svnadmin: attempted recovery leads to segfault
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
425036: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425036
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: subversion
Version: 1.4.2dfsg1-2
Severity: important
File: /usr/bin/svnadmin
After moving my svn repository from an i386 debian to an amd64 debian,
svnadmin crashes, and most seriously, also when I try to recover any data:
> svnadmin recover /home/svn/repository
Repository lock acquired.
Please wait; recovering the repository may take some time...
Segmentation fault (core dumped)
The core backtrace shows this:
Core was generated by `svnadmin recover /home/svn/repository'.
Program terminated with signal 11, Segmentation fault.
#0 0x00002ba024d950c1 in ?? () from /usr/lib/libdb-4.4.so
(gdb) bt
#0 0x00002ba024d950c1 in ?? () from /usr/lib/libdb-4.4.so
#1 0x00002ba024d95d22 in __db_e_attach () from /usr/lib/libdb-4.4.so
#2 0x00002ba024d95eb3 in __db_e_remove () from /usr/lib/libdb-4.4.so
#3 0x00002ba024d9397e in __env_open_pp () from /usr/lib/libdb-4.4.so
#4 0x00002ba02404fd31 in svn_fs_bdb__open () from
/usr/lib/libsvn_fs_base-1.so.1
#5 0x00002ba024056a80 in ?? () from /usr/lib/libsvn_fs_base-1.so.1
#6 0x00002ba023553bf6 in svn_fs_berkeley_recover () from
/usr/lib/libsvn_fs-1.so.1
#7 0x00002ba02337a543 in svn_repos_recover2 () from
/usr/lib/libsvn_repos-1.so.1
#8 0x0000000000402f5b in ?? ()
#9 0x000000000040456d in ?? ()
#10 0x00002ba023bf48e4 in __libc_start_main () from /lib/libc.so.6
#11 0x00000000004025ea in ?? ()
#12 0x00007fff877761e8 in ?? ()
#13 0x0000000000000000 in ?? ()
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.20-2007-05-14 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages subversion depends on:
ii libapr1 1.2.7-8.2 The Apache Portable Runtime Librar
ii libc6 2.5-7 GNU C Library: Shared libraries
ii libsvn1 1.4.2dfsg1-2 Shared libraries used by Subversio
subversion recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Fri, May 18, 2007 at 03:13:05PM -0500, Peter Samuelson wrote:
> reassign 425036 libdb4.4
> retitle 425036 libdb4.4: segfault reading an i386 db on amd64
> thanks
This was supposed to go to libdb4.4, but control@ wasn't Cced.
> [Elias Pschernig]
> > After moving my svn repository from an i386 debian to an amd64 debian,
> > svnadmin crashes, and most seriously, also when I try to recover any data:
>
> Turns out, yes, I can reproduce the segfault without Subversion -
> thanks Richard Nelson from IRC for suggesting db4.4_dump:
>
> [ on i386 ]
>
> svnadmin create --fs-type=bdb /tmp/repo
> svnlook tree /tmp/repo
>
> [ scp to an amd64 machine ]
>
> db4.4_dump -p /tmp/repo/db/changes
>
> The last step segfaults. db4.4_dump is happy to read a repository
> created natively on amd64.
Trying the repro with current versions of tools works, so I'm closing
this.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--- End Message ---
