Tue 05 Sep 2006 03:44:11 PM UTC, comment #5:
This sounds like a different problem -- next time could you file such things as a separate bug?
I don't know from what you pasted why you're getting a segfault -- the most common reason is linking to both libstdc++5 and libstdc++6 at the same time, and you're not doing that, but it doesn't tell me what it might actually be instead :-).
As a general point, this kind of problem pretty much always means a screwed up toolchain somehow, and experience suggests that it's particularly easy to get a screwed up toolchain on gentoo. I don't know what exactly this stack smashing patch is, but I can't imagine what monotone would do to run afoul of it; we don't do anything wonky with the stack. Comments #0 and #1 here might be helpful:
http://bugs.gentoo.org/show_bug.cgi?id=131044
Also, 0.26 is rather old at this point -- you might want to try 0.29. I believe it has just been enabled in portage, as well, so you should be able to get it that way.
If that still doesn't work, could we get a stack trace from gdb?
|
Tue 05 Sep 2006 02:11:59 PM UTC, comment #4:
I experience a situation that is even worse: whatever options I pass to mtn, or even with no options at all, I get:
$ ./mtn
?: fatal: signal: memory access violation
?:
?: this is almost certainly a bug in monotone.
?: please send this error message, the output of ' --full-version',
?: and a description of what you were doing to monotone-devel@nongnu.org.
?: discarding debug log, because I have nowhere to write it
?: (maybe you want --debug or --dump?)
I get the same with LANG=C, LANG=en_US.UTF-8, LANG=en_US.utf8, and LANG unset. I have no LC_* environment variables set.
I also have monotone 0.19 (from Gentoo's package system) working, using Boost 1.33.1. I compiled monotone 0.26 from the .tar.bz2 archive with the following commands:
$ ./configure; make
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: /var/tmp/portage/gcc-3.4.6-r1/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
In fact I suspect that maybe the stack-smashing protection patch applied to GCC might interfere with Monotone. I compiled this version of Monotone with pristine GCC 4.1.1 (no patches applied) on Solaris with no problems.
$ ldd $(which monotone) # that's the installed 0.19, which works
libdl.so.2 => /lib/libdl.so.2 (0x492e9000)
libboost_regex.so.1.33.1 => /usr/lib/libboost_regex.so.1.33.1 (0x4920d000)
libboost_date_time.so.1.33.1 => /usr/lib/libboost_date_time.so.1.33.1 (0x491f7000)
libboost_filesystem.so.1.33.1 => /usr/lib/libboost_filesystem.so.1.33.1 (0x491e2000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0x490ad000)
libm.so.6 => /lib/libm.so.6 (0x4908a000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 (0x4907f000)
libc.so.6 => /lib/libc.so.6 (0x48f61000)
/lib/ld-linux.so.2 (0x492f2000)
$ ldd ./mtn # that's the newly compiled mtn, crashes
libz.so.1 => /lib/libz.so.1 (0x542a8000)
libdl.so.2 => /lib/libdl.so.2 (0x542a3000)
libboost_regex.so.1.33.1 => /usr/lib/libboost_regex.so.1.33.1 (0x541c8000)
libboost_date_time.so.1.33.1 => /usr/lib/libboost_date_time.so.1.33.1 (0x541b2000)
libboost_filesystem.so.1.33.1 => /usr/lib/libboost_filesystem.so.1.33.1 (0x5419d000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0x54068000)
libm.so.6 => /lib/libm.so.6 (0x54045000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 (0x5403a000)
libc.so.6 => /lib/libc.so.6 (0x53f1c000)
/lib/ld-linux.so.2 (0x542be000)
|
Fri 23 Jun 2006 11:58:02 PM UTC, comment #2:
Actually, scratch that about the libraries -- it looks like you somehow have a broken locale implementation, that's going into an infinite recursion as soon as we try to print any localized text using the C++ locale API.
Does it work if you set LANG=C, LC_ALL=C, etc.? That would explain how the testsuite could work, since almost all of it runs in the C locale.
'mtn --debug --version' might be useful; it will at least dump out what locale is being used.
gcc 3.3.6 is getting quite old; it's possible it's just a libstdc++ bug that's been fixed since then.
|
Fri 23 Jun 2006 09:00:20 PM UTC, original submission:
I actualy have a working monotone v0.19. Trying to compile v0.26 and it compiles OK, it tests OK save 4 errors (see included testsuit.log file).
I'm on a Gentoo machine:
Kernel: 2.6.16-gentoo-r3 #2 PREEMPT
gcc: 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
The problem arrises when trying to use mtn.
trying: ./mtn --db=mt.mtn db init
>> segmentation fault
I'm unable to "--dump".
When using gdb (and mtn compiled with -g) here is the stack trace (partial - the first 149385 lines being identical):
-----Top-----
--snip snip---
#149385 0xb7e4a0a9 in std::has_facet<std::messages<wchar_t> > () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149386 0xb7e4a0a9 in std::has_facet<std::messages<wchar_t> > () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149387 0xb7e39032 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_group_int ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149388 0xb7e3a442 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_convert_int<unsigned long> ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149389 0xb7e39db0 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149390 0xb7e4fa62 in std::ostream::operator<< () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
#149391 0x08106d19 in boost::io::detail::put<char, std::char_traits<char>, std::allocator<char>, unsigned int const&> (x=@0xbfe91b18, specs=@0x8660270,
res=@0x8660274, buf=@0xbfe91cd8, loc_p=0xbfe91d3c) at ostream:204
#149392 0x080febf1 in boost::io::detail::distribute<char, std::char_traits<char>, std::allocator<char>, unsigned int const&> (self=@0xbfe91ca0, x=@0xbfe91b18)
at stl_vector.h:501
####This next line coredumps GDB
#149393 boost::basic_format<char, std::char_traits<char>, std::alocator<char> >& boost::io::detail::feed<char, std::char_traits<char>, std::allocator<char>, unsigned int const&>(boost::basic_format<char, std::char_traits<char>, std::allocator<char> >&, unsigned int const&)
#149394 sanity::gasp()
#149395 sanity::naughty_failure(std::string const&, i18n_format const&, std::string const&, int)
#149396 require_path_is_nonexistent(anny_path const&, i18n_format const&)
#149397 database__initialize()
#149398 commands::cmd_db::exec(app_state&, std::vector<utf8, std::allocator<utf8> > const&)
####This next line coredumps GDB
#149399 commands::process(app_state&, std::string const&, std::vector<utf8, std::allocator<utf8> > const&)
#149400 cpp_main(int, char**)
#149401 main_with_signal_handlers
####This next line coredumps GDB
#149402 main_with_many_flavours_of_exception
#149403 main
-----Top-----
For some of the lines, when printing the stack GDB coredumped (I had to use Insight and copy by hand the rest of the stack).
Hope this helps.
Thanks in advance.
|