Re: Subversion segmentation fault for 1 repository
On Sat, Aug 01, 2009 at 09:32:38PM +0100, Philip Martin wrote: Philip Martin phi...@codematters.co.uk writes: BDB databases are supposed to be portable from 32 to 64 bits: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/faq.html but if for some reason that doesn't work the last ditch solution is to dump the database on the 32 bit machine, transfer the dump, and load it on the 64 bit machine. It might be sufficient to remove the BDB shared-memory files repository/db/__db.00? on the 64 bit machine, they will get recreated automatically when you access the repository. Thank you very, very much Philip! That was sufficient, repository works fine now. Jakub -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
I've changed hardware in my server from i386 to AMD64 and everything works fine except one SVN repository. When I try to access it, there is following error: svn: OPTIONS z 'http://some.local.ip.address/svn/repo-name': Could not read status line: connection was closed by server (http://some.local.ip.address) in Apache error log: [notice] child pid 3504 exit signal Segmentation fault (11) I've thought it might me dav_svn issue but: svnadmin verify repo-name gives following result: Segmentation fault The same is with: svnadmin recover repo-name Repository lock acquired. Please wait; recovering the repository may take some time... Segmentation fault This repo is very big - server repo directory is 7.1 GB. Maybe this is a reason for that? All other repositories work fine, although they are much smaller. On i386 machine this repository, just copied from amd64 works fine. Any help will be appreciated. Regards, Jakub For me it seems as there is a bug in some libraries compiled for amd64. I've made following checks: - I downloaded newest subversion sources and compiled it. Result was the same as above that is Segmentation fault. - I installed ia32 chroot system with debootstrap and repository works fine on the same machine! Should I file a bug somewhere? Regards, Jakub -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Subversion segmentation fault for 1 repository
Hi, I've changed hardware in my server from i386 to AMD64 and everything works fine except one SVN repository. When I try to access it, there is following error: svn: OPTIONS z 'http://some.local.ip.address/svn/repo-name': Could not read status line: connection was closed by server (http://some.local.ip.address) in Apache error log: [notice] child pid 3504 exit signal Segmentation fault (11) I've thought it might me dav_svn issue but: svnadmin verify repo-name gives following result: Segmentation fault The same is with: svnadmin recover repo-name Repository lock acquired. Please wait; recovering the repository may take some time... Segmentation fault This repo is very big - server repo directory is 7.1 GB. Maybe this is a reason for that? All other repositories work fine, although they are much smaller. On i386 machine this repository, just copied from amd64 works fine. Any help will be appreciated. Regards, Jakub -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
The last part of strace:
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f20b974c000
read(4, # This is the configuration file ..., 4096) = 1738
read(4, ..., 4096)= 0
close(4)= 0
munmap(0x7f20b974c000, 4096)= 0
stat(/var/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
open(graphics/db/__db.register, O_RDWR|O_CREAT, 0660) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fcntl(4, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=1, len=1}) = 0
fstat(4, {st_mode=S_IFREG|0640, st_size=125, ...}) = 0
read(4,11370\n..., 25) = 25
fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
fcntl(4, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0
fstat(4, {st_mode=S_IFREG|0640, st_size=125, ...}) = 0
lseek(4, 0, SEEK_SET) = 0
write(4, X 0\n..., 25) = 25
write(4, X 0\n..., 25) = 25
write(4, X 0\n..., 25) = 25
write(4, X 0\n..., 25) = 25
write(4, X 0\n..., 25) = 25
lseek(4, 0, SEEK_SET) = 0
read(4, X 0\n..., 25) = 25
fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
lseek(4, 0, SEEK_SET) = 0
write(4,11376\n..., 25) = 25
open(graphics/db/__db.rep.init, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(graphics/db/__db.001, O_RDWR)= 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=24576, ...}) = 0
close(5)= 0
open(graphics/db/__db.001, O_RDWR)= 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
mmap(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x7f20b9747000
close(5)= 0
munmap(0x7f20b9747000, 12884901887) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Full output:
http://debian.pastebin.com/m3f148b4c
On Fri, Jul 31, 2009 at 05:12:05AM -0800, Dean Hamstead wrote:
run strace with svnadmin
Dean
On 7/31/2009, Jakub Nadolny jakub.nado...@carrywater.pl wrote:
Hi,
I've changed hardware in my server from i386 to AMD64 and everything works
fine
except one SVN repository.
When I try to access it, there is following error:
svn: OPTIONS z 'http://some.local.ip.address/svn/repo-name': Could not
read status line: connection was closed by server
(http://some.local.ip.address)
in Apache error log:
[notice] child pid 3504 exit signal Segmentation fault (11)
I've thought it might me dav_svn issue but:
svnadmin verify repo-name
gives following result:
Segmentation fault
The same is with:
svnadmin recover repo-name
Repository lock acquired.
Please wait; recovering the repository may take some time...
Segmentation fault
This repo is very big - server repo directory is 7.1 GB. Maybe this is a
reason
for that? All other repositories work fine, although they are much smaller.
On i386 machine this repository, just copied from amd64 works fine.
Any help will be appreciated.
Regards,
Jakub
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Subversion segmentation fault for 1 repository
On Fri, Jul 31, 2009 at 01:15:29PM -0700, Jeff D wrote: On Fri, 31 Jul 2009, Jakub Nadolny wrote: Hi, I've changed hardware in my server from i386 to AMD64 and everything works fine except one SVN repository. When I try to access it, there is following error: svn: OPTIONS z 'http://some.local.ip.address/svn/repo-name': Could not read status line: connection was closed by server (http://some.local.ip.address) in Apache error log: [notice] child pid 3504 exit signal Segmentation fault (11) I've thought it might me dav_svn issue but: svnadmin verify repo-name gives following result: Segmentation fault The same is with: svnadmin recover repo-name Repository lock acquired. Please wait; recovering the repository may take some time... Segmentation fault This repo is very big - server repo directory is 7.1 GB. Maybe this is a reason for that? All other repositories work fine, although they are much smaller. On i386 machine this repository, just copied from amd64 works fine. Any help will be appreciated. Regards, Jakub I doubt its the size of the repository, I have a few that are well over 40G. How did you migrate your repository? Perhaps something got corrupted in the transfer? I've just copied repository directory from old disk to new one. Repository is not corrupted - to check it I've copied it again from new disk to another machine (i386) and then it works fine, svnadmin verify shows no errors. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: iptables on amd64 kernel
On Mon, Jul 11, 2005 at 12:33:57PM -0500, Stephen Olander Waters wrote: On Mon, 2005-07-11 at 19:14 +0200, Jakub Nadolny wrote: On Mon, Jul 11, 2005 at 11:12:12AM -0500, Stephen Olander Waters wrote: On Mon, 2005-07-11 at 11:45 +0200, Jörg Ebeling wrote: Hi Jakub, I've the same on a server machine since weeks. I could solve the problem by installing the 'amd64-libs' and a manually install of 'iptables_1.2.11-10_amd64.deb' with '--force-architecture'. Well it works without any further problems (by me). The annoying thing is that apt/aptitude always tries to update the iptables package. I did the same thing except I put an = next to it in dselect to keep it from getting upgraded. I have no idea why it does not work on my machine... Well, we both have 1.2.11 -- you should try that older version instead of 1.3.2. Yes! That was it, thank you very much! BTW - if I would like to upgrade from i386 distro to amd64 - is it possible to do it with apt or I have to reinstall whole system? I have tried to do it by changing APT::Architecture i386; to amd64 and changing sources.list to deb ftp://ftp.de.debian.org/debian-amd64/debian/ testing main contrib but there were errors e.g. with libc6 upgrade. I could not manage it. I have one more question - for production servers do you all use stable distro? Up to now I have used testing, but after this accident with iptables I started to thing about it once more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
iptables on amd64 kernel
Hi, I have just upgraded my hardware to AMD64 and installed kernel-image 2.6.8-11-amd64-k8. So all packages remain in i386 version. Everything works fine, but iptables does not work: # iptables -L iptables v1.3.1: can't initialize iptables table `filter': Bad file descriptor Perhaps iptables or your kernel needs to be upgraded. Kernel and iptables upgrade did not help. Can I ask you for help? What should I do to have iptables running with amd64 kernel? I have installed also iptables_1.3.1-2_amd64.deb (with --force-all), but result is the same. I use Debian testing. Thank you in advance! Jakub -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
