subversion: svn update hang in an endless loop, svnadmin recover crashes

[Debian Bug Importer]

Automatically imported from Debian bug report #266949 http://bugs.debian.org/266949

[Petr Sebor (petr-scssoft)]

Package: subversion
Version: 1.0.6-1.1
Followup-For: Bug #266949

it dies exactly the same way when recovering database with db4.2_recover

Petr

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8
Locale: LANG=C, LC_CTYPE=C

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-16.amd64.2 Berkeley v4.2 Database Utilities
ii libapr0 2.0.50-9 The Apache Portable Runtime
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16.amd64.2 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.6-8 XML parsing C library - runtime li
ii libldap2 2.1.30-3 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-0.1 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7d-5 SSL shared libraries
ii libsvn0 1.0.6-1.1 Shared libraries used by Subversio
ii libxml2 2.6.11-3 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.1.1-5 compression library - runtime

-- no debconf information

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #266949 http://bugs.debian.org/266949

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 19 Aug 2004 23:09:09 +0200
From: Petr Sebor <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: svn update hang in an endless loop, svnadmin recover crashes

Package: subversion
Version: 1.0.6-1.1
Severity: grave
Justification: renders package unusable

after switching the entire system over to the amd64 port, svn update
lockups in an endless loop

problem originally reported here:
http://lists.debian.org/debian-amd64/2004/07/msg00256.html

Andreas Richter replied:
http://lists.debian.org/debian-amd64/2004/07/msg00257.html

but svnadmin recover dies on every attempt, on every repository...
Please wait; recovering the repository may take some time...
Segmentation fault

from dmesg:
svnadmin[8842]: segfault at 000000399556cefc rip 0000002a95ed085e rsp
0000007fbffff4d0 error 4

I can see this in strace:
write(1, "Please wait; recovering the repo"..., 61Please wait; recovering
the repository may take some time...
) = 61
open("repos/format", O_RDONLY) = 3
read(3, "3\n", 80) = 2
close(3) = 0
open("repos/locks/db.lock", O_RDWR) = 3
fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/etc/mtab", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=220, ...}) = 0
mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(4, "/dev/hda1 / reiserfs rw 0 0\nproc"..., 131072) = 220
close(4) = 0
munmap(0x2a9556b000, 131072) = 0
open("/proc/stat", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a9556b000
read(4, "cpu 7153 20 3205 4332827 12047 "..., 1024) = 701
read(4, "", 1024) = 0
close(4) = 0
munmap(0x2a9556b000, 4096) = 0
stat("repos/db/DB_CONFIG", {st_mode=S_IFREG|0664, st_size=1738, ...}) = 0
open("repos/db/DB_CONFIG", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0664, st_size=1738, ...}) = 0
mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(4, "# This is the configuration file"..., 131072) = 1738
read(4, "", 131072) = 0
close(4) = 0
munmap(0x2a9556b000, 131072) = 0
stat("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=80, ...}) = 0
stat("repos/db/__db.001", {st_mode=S_IFREG|0664, st_size=8192, ...}) = 0
open("repos/db/__db.001", O_RDWR) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0664, st_size=8192, ...}) = 0
close(4) = 0
open("repos/db/__db.001", O_RDWR) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2a9556b000
close(4) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Thanks!
Petr

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8
Locale: LANG=...

[Petr Sebor (petr-scssoft)]

as reported here...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255834

probably dumping on i386 and reloading on amd64 might do the trick

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 19 Aug 2004 23:37:45 +0200
From: Petr Sebor <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: looks like the problem is actually in libdb4.2 ...

Package: subversion
Version: 1.0.6-1.1
Followup-For: Bug #266949

it dies exactly the same way when recovering database with db4.2_recover

Petr

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8
Locale: LANG=C, LC_CTYPE=C

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-16.amd64.2 Berkeley v4.2 Database Utilities
ii libapr0 2.0.50-9 The Apache Portable Runtime
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16.amd64.2 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.6-8 XML parsing C library - runtime li
ii libldap2 2.1.30-3 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-0.1 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7d-5 SSL shared libraries
ii libsvn0 1.0.6-1.1 Shared libraries used by Subversio
ii libxml2 2.6.11-3 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.1.1-5 compression library - runtime

-- no debconf information

[Adam Conrad (adconrad-trinitysoftware)]

I'll let the SVN maintainers pick an appropriate severity, but this can't
possibly be grave for 2 reasons:

1) amd64 isn't a release arch
2) Randomly moving files from one arch to another and expecting them to work
generally doesn't. alpha -> i386 no doubt has similar issues.

... Adam

--
backup [n] (bak'up): The duplicate copy of crucial data that no one
                     bothered to make; used only in the abstract.

1024D/C6CEA0C9 C8B2 CB3E 3225 49BB 5ED2 0002 BE3C ED47 C6CE A0C9

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 20 Aug 2004 01:06:51 +0200
From: Petr Sebor <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: it is actually known db4.2 problem

as reported here...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255834

probably dumping on i386 and reloading on amd64 might do the trick

[Debian Bug Importer (debzilla)]

Message-ID: <004a01c48645$ada2a780$<email address hidden>>
Date: Fri, 20 Aug 2004 09:38:48 +1000
From: "Adam Conrad" <email address hidden>
To: <email address hidden>
Subject: subversion: svn update hang in an endless loop, svnadmin recover crashes

I'll let the SVN maintainers pick an appropriate severity, but this =
can't
possibly be grave for 2 reasons:

1) amd64 isn't a release arch
2) Randomly moving files from one arch to another and expecting them to =
work
generally doesn't. alpha -> i386 no doubt has similar issues.

... Adam

--
backup [n] (bak'up): The duplicate copy of crucial data that no one
                     bothered to make; used only in the abstract.

1024D/C6CEA0C9 C8B2 CB3E 3225 49BB 5ED2 0002 BE3C ED47 C6CE A0C9
=20

[Laszlo Boszormenyi (gcs)]

package subversion
severity 266949 normal
reassign 266949 libdb4.2
merge 255834 266949
thanks

* Petr Sebor <email address hidden> [2004-08-20 01:06:51 +0200]:

> probably dumping on i386 and reloading on amd64 might do the trick
 I think there is no 'probably'; that's the correct way of switching
archs, especially between 32 bit and 64 bit ones. For reference please
see how to dump[1] and reload[2] it. Please note that it will include
only the repository itself; you have to manually move your hooks and co.

* Adam Conrad <email address hidden> [2004-08-20 09:38:48 +1000]:

> I'll let the SVN maintainers pick an appropriate severity, but this can't
> possibly be grave for 2 reasons:
>
> 1) amd64 isn't a release arch
> 2) Randomly moving files from one arch to another and expecting them to work
> generally doesn't. alpha -> i386 no doubt has similar issues.
 Totally agree.

Regards,
Laszlo/GCS
[1] http://svnbook.red-bean.com/svnbook/re31.html
[2] http://svnbook.red-bean.com/svnbook/re36.html

[Debian Bug Importer (debzilla)]

Message-ID: <20040820030944.GA19388@pooh>
Date: Fri, 20 Aug 2004 05:09:44 +0200
From: Laszlo 'GCS' Boszormenyi <email address hidden>
To: Petr Sebor <email address hidden>,
 Adam Conrad <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#266949: subversion: svn update hang in an endless loop, svnadmin recover crashes

package subversion
severity 266949 normal
reassign 266949 libdb4.2
merge 255834 266949
thanks

* Petr Sebor <email address hidden> [2004-08-20 01:06:51 +0200]:

> probably dumping on i386 and reloading on amd64 might do the trick
 I think there is no 'probably'; that's the correct way of switching
archs, especially between 32 bit and 64 bit ones. For reference please
see how to dump[1] and reload[2] it. Please note that it will include
only the repository itself; you have to manually move your hooks and co.

* Adam Conrad <email address hidden> [2004-08-20 09:38:48 +1000]:

> I'll let the SVN maintainers pick an appropriate severity, but this can't
> possibly be grave for 2 reasons:
>
> 1) amd64 isn't a release arch
> 2) Randomly moving files from one arch to another and expecting them to work
> generally doesn't. alpha -> i386 no doubt has similar issues.
 Totally agree.

Regards,
Laszlo/GCS
[1] http://svnbook.red-bean.com/svnbook/re31.html
[2] http://svnbook.red-bean.com/svnbook/re36.html

[Petr Sebor (petr-scssoft)]

Laszlo 'GCS' Boszormenyi wrote:

>I think there is no 'probably'; that's the correct way of switching
>archs, especially between 32 bit and 64 bit ones. For reference please
>see how to dump[1] and reload[2] it. Please note that it will include
>only the repository itself; you have to manually move your hooks and co.
>
>
Right. It worked. I wasn't sure at the time of my writing though... I
had quite some time ahead
since the dump/load process is quite consuming.

>* Adam Conrad <email address hidden> [2004-08-20 09:38:48 +1000]:
>
>
>
>>I'll let the SVN maintainers pick an appropriate severity, but this can't
>>possibly be grave for 2 reasons:
>>
>>1) amd64 isn't a release arch
>>
>>
Grave is really not the right severity. I agree...

>>2) Randomly moving files from one arch to another and expecting them to work
>>generally doesn't. alpha -> i386 no doubt has similar issues.
>>
>>
Well, I generally don't expect that to work. A little warning like 'you
fool, your database was created on different
arch and has no chance of working' would help though, segfault and
deadlock does not.

Thanks,
Petr Sebor

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 20 Aug 2004 11:20:55 +0200
From: Petr Sebor <email address hidden>
To: Laszlo 'GCS' Boszormenyi <email address hidden>
Cc: Adam Conrad <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#266949: subversion: svn update hang in an endless loop, svnadmin
 recover crashes

Laszlo 'GCS' Boszormenyi wrote:

>I think there is no 'probably'; that's the correct way of switching
>archs, especially between 32 bit and 64 bit ones. For reference please
>see how to dump[1] and reload[2] it. Please note that it will include
>only the repository itself; you have to manually move your hooks and co.
>
>
Right. It worked. I wasn't sure at the time of my writing though... I
had quite some time ahead
since the dump/load process is quite consuming.

>* Adam Conrad <email address hidden> [2004-08-20 09:38:48 +1000]:
>
>
>
>>I'll let the SVN maintainers pick an appropriate severity, but this can't
>>possibly be grave for 2 reasons:
>>
>>1) amd64 isn't a release arch
>>
>>
Grave is really not the right severity. I agree...

>>2) Randomly moving files from one arch to another and expecting them to work
>>generally doesn't. alpha -> i386 no doubt has similar issues.
>>
>>
Well, I generally don't expect that to work. A little warning like 'you
fool, your database was created on different
arch and has no chance of working' would help though, segfault and
deadlock does not.

Thanks,
Petr Sebor

[Matt Zimmerman (mdz)]

Sounds like a feature request to provide portability of the svn repository

[Jason Toffaletti (jason)]

subversion 1.2 defaults to using the file system repository type, which
shouldn't have this issue. I think it only occurs because of portability issues
with BerkleyDB, as noted here
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255834. I can't find any
related upstream bugs/enhancement requests so I'm recommending this be closed.

[Dennis Kaarsemaker (dennis)]

Closing as WONTFIX - no activity in over a year and this really is not an issue
a distributor should try to resolve.