Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
Zack Weinberg wrote: On Thu, Apr 9, 2009 at 9:45 PM, Gary Kramlich g...@reaperworld.com wrote: $ which mtn; sudo which mtn /usr/bin/mtn /usr/bin/mtn But it does get weirder, it works fine for other users on my machine. Just not me. So this is obviously some crazy config problem. However, I did move ~/.monotone out of the way and it's still having problems. It's never getting to the point at which it would look at anything in .monotone. Oh, hey, do you have any LD_* variables set in your environment? Try clearing them. $ set | grep LD | wc -l 0 However, i've noticed that the offsets are completely different between my user, another, and root's in the ldd output, and honestly, I have no idea if thats correct or not. Shared library load addresses should be consistent across users for the same binary. Could you post the ldd output for a user where mtn is broken, and for one where it works? Broken ldd output: linux-vdso.so.1 = (0x7fff2f1ff000) libpcre.so.3 = /usr/lib/libpcre.so.3 (0x7fd126cfb000) libbotan-1.8.1.so = /usr/lib/libbotan-1.8.1.so (0x7fd126842000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fd126627000) librt.so.1 = /lib/librt.so.1 (0x7fd12641f000) liblua5.1.so.0 = /usr/lib/liblua5.1.so.0 (0x7fd1261f4000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7fd125f68000) libidn.so.11 = /usr/lib/libidn.so.11 (0x7fd125d36000) libz.so.1 = /usr/lib/libz.so.1 (0x7fd125b1f000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd125813000) libm.so.6 = /lib/libm.so.6 (0x7fd12559) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd125379000) libc.so.6 = /lib/libc.so.6 (0x7fd125026000) /lib64/ld-linux-x86-64.so.2 (0x7fd126f2a000) libdl.so.2 = /lib/libdl.so.2 (0x7fd124e22000) libicui18n.so.40 = /usr/lib/libicui18n.so.40 (0x7fd124a8d000) libicuuc.so.40 = /usr/lib/libicuuc.so.40 (0x7fd124742000) libicudata.so.40 = /usr/lib/libicudata.so.40 (0x7fd1237fd000) Other user, works fine ldd output: linux-vdso.so.1 = (0x7fff675ff000) libpcre.so.3 = /usr/lib/libpcre.so.3 (0x7fed5f12c000) libbotan-1.8.1.so = /usr/lib/libbotan-1.8.1.so (0x7fed5ec73000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fed5ea58000) librt.so.1 = /lib/librt.so.1 (0x7fed5e85) liblua5.1.so.0 = /usr/lib/liblua5.1.so.0 (0x7fed5e625000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7fed5e399000) libidn.so.11 = /usr/lib/libidn.so.11 (0x7fed5e167000) libz.so.1 = /usr/lib/libz.so.1 (0x7fed5df5) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fed5dc44000) libm.so.6 = /lib/libm.so.6 (0x7fed5d9c1000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fed5d7aa000) libc.so.6 = /lib/libc.so.6 (0x7fed5d457000) /lib64/ld-linux-x86-64.so.2 (0x7fed5f35b000) libdl.so.2 = /lib/libdl.so.2 (0x7fed5d253000) libicui18n.so.40 = /usr/lib/libicui18n.so.40 (0x7fed5cebe000) libicuuc.so.40 = /usr/lib/libicuuc.so.40 (0x7fed5cb73000) libicudata.so.40 = /usr/lib/libicudata.so.40 (0x7fed5bc2e000) root's ldd output, works fine: linux-vdso.so.1 = (0x7fff571ff000) libpcre.so.3 = /usr/lib/libpcre.so.3 (0x7f294ed47000) libbotan-1.8.1.so = /usr/lib/libbotan-1.8.1.so (0x7f294e88e000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f294e673000) librt.so.1 = /lib/librt.so.1 (0x7f294e46b000) liblua5.1.so.0 = /usr/lib/liblua5.1.so.0 (0x7f294e24) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7f294dfb4000) libidn.so.11 = /usr/lib/libidn.so.11 (0x7f294dd82000) libz.so.1 = /usr/lib/libz.so.1 (0x7f294db6b000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f294d85f000) libm.so.6 = /lib/libm.so.6 (0x7f294d5dc000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f294d3c5000) libc.so.6 = /lib/libc.so.6 (0x7f294d072000) /lib64/ld-linux-x86-64.so.2 (0x7f294ef76000) libdl.so.2 = /lib/libdl.so.2 (0x7f294ce6e000) libicui18n.so.40 = /usr/lib/libicui18n.so.40 (0x7f294cad9000) libicuuc.so.40 = /usr/lib/libicuuc.so.40 (0x7f294c78e000) libicudata.so.40 = /usr/lib/libicudata.so.40 (0x7f294b849000) thanks, zw -- Gary Kramlich g...@reaperworld.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
Zack Weinberg wrote: On Thu, Apr 9, 2009 at 9:45 PM, Gary Kramlich g...@reaperworld.com wrote: $ which mtn; sudo which mtn /usr/bin/mtn /usr/bin/mtn But it does get weirder, it works fine for other users on my machine. Just not me. So this is obviously some crazy config problem. However, I did move ~/.monotone out of the way and it's still having problems. It's never getting to the point at which it would look at anything in .monotone. Oh, hey, do you have any LD_* variables set in your environment? Try clearing them. However, i've noticed that the offsets are completely different between my user, another, and root's in the ldd output, and honestly, I have no idea if thats correct or not. Shared library load addresses should be consistent across users for the same binary. Could you post the ldd output for a user where mtn is broken, and for one where it works? thanks, zw Hey, I figured it out, and please don't kill me... Turns out i had an older version in ~/bin which wasn't working because ~/bin wasn't getting added to my path before. Sorry for the noise, but thank you very much for the help. Btw, debsums is awesome, looks very helpful :) -- Gary Kramlich g...@reaperworld.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
On Wed, Apr 8, 2009 at 9:09 PM, Gary Kramlich g...@reaperworld.com wrote: any invocation of mtn is causing a segfault. I have a core, but contains a single frame of: #0 0x in _start () from /lib64/ld-linux-x86-64.so.2 Even a simple mtn --version outside of a working copy results in a segfault. This is not reproducible on my system, which is also amd64 sid with the same versions for all dependent libraries. Crashing in _start() suggests that some library or executable on the system is corrupted. Please install the debsums package and run this command: # debsums -s monotone libbotan1.8 libc6 libgcc1 libidn11 liblua5.1-0 libpcre3 libsqlite3-0 libstdc++6 zlib1g If this prints any lines of the form debsums: checksum mismatch libpcre3 file /usr/lib/libpcreposix.so.3.12.1 then please reinstall the packages named right after checksum mismatch (libpcre3, in the example). And let us know if that solves the problem. You may also want to run a forcible fsck and/or a hard drive sector read test. If this advice does *not* solve the problem, then please post the complete output of this command: $ LD_DEBUG=files mtn --version Thanks, zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
On Thu, Apr 9, 2009 at 5:25 AM, Ludovic Brenta ludo...@ludovic-brenta.org wrote: Zack, can you reproduce this bug? Should I wait for a resolution before I upload 0.43-2, or can I proceed? I plan to upload this evening (~7 hours from now) or tomorrow. I cannot reproduce the bug, and to me it looks like a damaged shared library on the reporter's system. I've responded to them asking for more information. Please go ahead with 0.43-2. zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
Zack Weinberg wrote: On Wed, Apr 8, 2009 at 9:09 PM, Gary Kramlich g...@reaperworld.com wrote: any invocation of mtn is causing a segfault. I have a core, but contains a single frame of: #0 0x in _start () from /lib64/ld-linux-x86-64.so.2 Even a simple mtn --version outside of a working copy results in a segfault. This is not reproducible on my system, which is also amd64 sid with the same versions for all dependent libraries. Crashing in _start() suggests that some library or executable on the system is corrupted. Please install the debsums package and run this command: # debsums -s monotone libbotan1.8 libc6 libgcc1 libidn11 liblua5.1-0 libpcre3 libsqlite3-0 libstdc++6 zlib1g If this prints any lines of the form debsums: checksum mismatch libpcre3 file /usr/lib/libpcreposix.so.3.12.1 then please reinstall the packages named right after checksum mismatch (libpcre3, in the example). And let us know if that solves the problem. You may also want to run a forcible fsck and/or a hard drive sector read test. If this advice does *not* solve the problem, then please post the complete output of this command: $ LD_DEBUG=files mtn --version Thanks, zw debsums found nothing. all my filesystems were in pretty bad shape, somehow the journals kept them alive. They're all clean now, problem persists. Here's the output using LD_DEBUG g...@cloak:~$ LD_DEBUG=files mtn --version 8031: 8031: file=libm.so.6 [0]; needed by mtn [0] 8031: file=libm.so.6 [0]; generating link map 8031: dynamic: 0xf7f30ef0 base: 0xf7f0e000 size: 0x00023080 8031: entry: 0xf7f11410 phdr: 0xf7f0e034 phnum: 9 8031: 8031: 8031: file=libc.so.6 [0]; needed by mtn [0] 8031: file=libc.so.6 [0]; generating link map 8031: dynamic: 0xf7f09d7c base: 0xf7db6000 size: 0x00157650 8031: entry: 0xf7dcc87e phdr: 0xf7db6034 phnum: 10 8031: 8031: 8031: calling init: /lib32/libc.so.6 8031: 8031: 8031: calling init: /lib32/libm.so.6 8031: 8031: 8031: initialize program: mtn 8031: Segmentation fault -- Gary Kramlich g...@reaperworld.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
Zack Weinberg wrote: On Wed, Apr 8, 2009 at 9:09 PM, Gary Kramlich g...@reaperworld.com wrote: any invocation of mtn is causing a segfault. I have a core, but contains a single frame of: #0 0x in _start () from /lib64/ld-linux-x86-64.so.2 Even a simple mtn --version outside of a working copy results in a segfault. This is not reproducible on my system, which is also amd64 sid with the same versions for all dependent libraries. Crashing in _start() suggests that some library or executable on the system is corrupted. Please install the debsums package and run this command: # debsums -s monotone libbotan1.8 libc6 libgcc1 libidn11 liblua5.1-0 libpcre3 libsqlite3-0 libstdc++6 zlib1g If this prints any lines of the form debsums: checksum mismatch libpcre3 file /usr/lib/libpcreposix.so.3.12.1 then please reinstall the packages named right after checksum mismatch (libpcre3, in the example). And let us know if that solves the problem. You may also want to run a forcible fsck and/or a hard drive sector read test. If this advice does *not* solve the problem, then please post the complete output of this command: $ LD_DEBUG=files mtn --version Thanks, zw Ok, it get's even weirder... mtn works fine on tty0, but fails under X. Also, works fine as root under X. $ mtn --version Segmentation fault $ sudo mtn --version monotone 0.43 (base revision: ddc6546051abf6475c40a3fdba272e2f82a40e94) I moved ~/.monotone out of the way, and that didn't make a difference. I'm comparing environment variables at the moment, but haven't come across anything yet. Going to try tinkering with $PATH next. -- Gary Kramlich g...@reaperworld.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
On Thu, Apr 9, 2009 at 6:57 PM, Gary Kramlich g...@reaperworld.com wrote: debsums found nothing. all my filesystems were in pretty bad shape, somehow the journals kept them alive. They're all clean now, problem persists. Ok. g...@cloak:~$ LD_DEBUG=files mtn --version 8031: 8031: file=libm.so.6 [0]; needed by mtn [0] 8031: file=libm.so.6 [0]; generating link map 8031: dynamic: 0xf7f30ef0 base: 0xf7f0e000 size: 0x00023080 8031: entry: 0xf7f11410 phdr: 0xf7f0e034 phnum: 9 8031: file=libc.so.6 [0]; needed by mtn [0] 8031: file=libc.so.6 [0]; generating link map 8031: dynamic: 0xf7f09d7c base: 0xf7db6000 size: 0x00157650 8031: entry: 0xf7dcc87e phdr: 0xf7db6034 phnum: 10 8031: calling init: /lib32/libc.so.6 8031: calling init: /lib32/libm.so.6 8031: initialize program: mtn Segmentation fault Something is very, very wrong here. The 0.43 mtn binary is linked against many more libraries than that, and that output is showing 32-bit pointers and loading libs from /lib32. Are you sure the package you've got is the official sid package of monotone 0.43? What does 'ldd /usr/bin/mtn' print? What is the first stanza of /usr/share/doc/monotone/changelog.Debian.gz ? zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
On Thu, Apr 9, 2009 at 8:11 PM, Gary Kramlich g...@reaperworld.com wrote: Also, works fine as root under X. $ mtn --version Segmentation fault $ sudo mtn --version monotone 0.43 (base revision: ddc6546051abf6475c40a3fdba272e2f82a40e94) That plus the other output you posted does suggest a path problem - maybe you have a locally built, 32-bit, broken 'mtn' binary in /usr/local/bin for some reason? zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
Zack Weinberg wrote: On Thu, Apr 9, 2009 at 8:11 PM, Gary Kramlich g...@reaperworld.com wrote: Also, works fine as root under X. $ mtn --version Segmentation fault $ sudo mtn --version monotone 0.43 (base revision: ddc6546051abf6475c40a3fdba272e2f82a40e94) That plus the other output you posted does suggest a path problem - maybe you have a locally built, 32-bit, broken 'mtn' binary in /usr/local/bin for some reason? zw Nope, it's the same, and I never built monotone. $ which mtn; sudo which mtn /usr/bin/mtn /usr/bin/mtn But it does get weirder, it works fine for other users on my machine. Just not me. So this is obviously some crazy config problem. However, I did move ~/.monotone out of the way and it's still having problems. However, i've noticed that the offsets are completely different between my user, another, and root's in the ldd output, and honestly, I have no idea if thats correct or not. -- Gary Kramlich g...@reaperworld.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523261: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation
On Thu, Apr 9, 2009 at 9:45 PM, Gary Kramlich g...@reaperworld.com wrote: $ which mtn; sudo which mtn /usr/bin/mtn /usr/bin/mtn But it does get weirder, it works fine for other users on my machine. Just not me. So this is obviously some crazy config problem. However, I did move ~/.monotone out of the way and it's still having problems. It's never getting to the point at which it would look at anything in .monotone. Oh, hey, do you have any LD_* variables set in your environment? Try clearing them. However, i've noticed that the offsets are completely different between my user, another, and root's in the ldd output, and honestly, I have no idea if thats correct or not. Shared library load addresses should be consistent across users for the same binary. Could you post the ldd output for a user where mtn is broken, and for one where it works? thanks, zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
