On Thu, Dec 15, 2005 at 02:02:20PM +0200, Brian Nelson wrote: > The backtrace for that crash on my machine looks like: > > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0x4a3ad691 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0x4a3aef5b in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0x4a3e3bb7 in __libc_message () from /lib/tls/i686/cmov/libc.so.6 > #4 0x4a3ea187 in _int_free () from /lib/tls/i686/cmov/libc.so.6 > #5 0x4a3ea622 in free () from /lib/tls/i686/cmov/libc.so.6 > #6 0x410e8dc1 in operator delete () from /usr/lib/libstdc++.so.6 > #7 0xb7a47dea in scim::CommonLookupTable::~CommonLookupTable () > from /usr/lib/libscim-1.0.so.8 > [rest of backtrace snipped] > I don't see how libaspell could be blamed...
If you think that the backtrace indicates that another fix might be available, and that rebuilding aspell is avoidable / merely papering over a problem, then that would be good, as it would also avoid needing to get people to upgrade libaspell15 (via Conflicts in libstdc++6, or even more obtrusive); and (more importantly) the fix that avoids needing to rebuild aspell might also avoid needing to rebuild other libraries. Unfortunately I can't think right now how to find another fix, but maybe you or the libstdc++6 maintainers will have an idea. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
