On Thu, Dec 15, 2005 at 02:02:20PM +0200, Brian Nelson wrote: > I don't see how libaspell could be blamed...
"blame" may not be the appropriate concept; but the relevant point is that installing recompiled libaspell fixed the problem for me. (Also relevant, though I didn't mention it in my bug report, is that the crash only appeared after I upgraded libstdc++6 from 4.0.2-2 to 4.0.2-5, giving further evidence that the cause of the crash is related to the libstdc++ change and that recompiling against the newer libstdc++ might fix the problem for others.) > 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 Note that this is a crash in memory deallocation; so it seems entirely reasonable that this crash is due to the change in default memory allocators, and thus reasonable that recompiling aspell to use the new allocation defaults might fix the problem -- and indeed it seems to have fixed the problem for me. Granted, the caller here (#7) is scim rather than aspell. Without having thought much about it, I suppose that this can occur because of the aggregation of allocations that libstdc++ does. However, I'm not familiar with libstdc++ memory allocation, and this suggested cause is pure speculation. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
