On Sun, Sep 03, 2006 at 04:37:24PM -0700, Ross Boylan <[EMAIL PROTECTED]> was heard to say: > Here's the stack trace, which seems to indicate something going wrong > in libc (or the kernel?), with libstdc++ possibly adding another layer > of error on top of that. > > I don't know if the low-level exception is considered normal enough > that it should be caught and dealt with. An excerpt from the gdb > session follows, and then some more background info:
[snip] > (gdb) backtrace > #0 0xffffe410 in __kernel_vsyscall () > #1 0xa7c6c6d1 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xa7c6df9b in abort () from /lib/tls/i686/cmov/libc.so.6 These three calls are just the program aborting itself due to the uncaught exception. > #3 0xa7e61644 in __gnu_cxx::__verbose_terminate_handler () > from /usr/lib/libstdc++.so.6 > #4 0xa7e5f035 in std::set_unexpected () from /usr/lib/libstdc++.so.6 > #5 0xa7e5f072 in std::terminate () from /usr/lib/libstdc++.so.6 These are the C++ library's sequence for aborting due to an uncaught exception. > #6 0xa7e5f1aa in __cxa_throw () from /usr/lib/libstdc++.so.6 This is the function g++ invokes to throw an exception. > #7 0xa7df410f in std::__throw_logic_error () from /usr/lib/libstdc++.so.6 Intermediate exception-throwing routine. > #8 0xa7e3ab5f in std::string::_S_copy_chars () from /usr/lib/libstdc++.so.6 > #9 0xa7e3aca9 in std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 These are presumably the std::string constructor. My guess is that we're passing NULL at some point to the constructor that makes a string from a char*. > #10 0xa7f8210f in pkgDPkgPM::Go () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 > #11 0xa7f321f0 in pkgPackageManager::DoInstall () > from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 These are the libapt routines that are supposed to invoke dpkg and handle its return code. > #12 0x0820e89b in download_install_manager::execute_install_run ( > this=0xafdd6f0c, res=pkgAcquire::Continue, [EMAIL PROTECTED]) > at download_install_manager.cc:136 This is the aptitude-side invocation of dpkg (via the above calls). It doesn't even pass in a string of any sort. The rest is just aptitude calls. If it's not too much trouble, I wonder if I could suggest that you build a debug apt too? I believe you can do this by fetching the source and running "DEB_BUILD_OPTIONS=noopt,nostrip dpkg-buildpackage -rfakeroot" in the root of the source package, then installing the resulting binaries. Daniel
signature.asc
Description: Digital signature
