--- Begin Message ---
Subject: |
monotone segfaulting on any invocation |
Date: |
Wed, 08 Apr 2009 23:09:33 -0500 |
Package: monotone
Version: 0.43-1
Severity: important
any invocation of mtn is causing a segfault. I have a core, but contains a
single frame of:
#0 0x0000000000000000 in _start () from /lib64/ld-linux-x86-64.so.2
Even a simple "mtn --version" outside of a working copy results in a segfault.
Not really sure how to proceed, but right now this is completely reproducable,
and was working as recently as 2 days ago with no updates to the system.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
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 monotone depends on:
ii libbotan1.8 1.8.1-1 multiplatform crypto library
ii libc6 2.9-7 GNU C Library: Shared libraries
ii libgcc1 1:4.3.3-5 GCC support library
ii libidn11 1.12-1 GNU Libidn library, implementation
ii liblua5.1-0 5.1.4-2 Simple, extensible, embeddable pro
ii libpcre3 7.8-2 Perl 5 Compatible Regular Expressi
ii libsqlite3-0 3.6.12-1 SQLite 3 shared library
ii libstdc++6 4.3.3-5 The GNU Standard C++ Library v3
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
monotone recommends no packages.
Versions of packages monotone suggests:
pn monotone-doc <none> (no description available)
pn monotone-server <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
Subject: |
Re: [Monotone-debian] Bug#523261: monotone segfaulting on any invocation |
Date: |
Fri, 10 Apr 2009 10:20:52 -0700 |
Package: monotone
Version: 0.43-1
On Fri, Apr 10, 2009 at 10:16 AM, Gary Kramlich <address@hidden> wrote:
> 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 :)
No worries. I'm glad we managed to figure it out. By the way, I
remembered that there's this "address space randomization" thing that
will make dynamic library load addresses change from run to run, so
that's probably not to worry about either.
Closing the bug report.
zw
--- End Message ---