On Feb 2, 2010, at 8:11 PM, David Blanton wrote: > 4 libstdc++.6.dylib 0x95628fda > __gnu_cxx::__verbose_terminate_handler() + 433 > 5 libstdc++.6.dylib 0x9562717a __cxxabiv1::__terminate(void > (*)()) + 10 > 6 libstdc++.6.dylib 0x956271ba > __cxxabiv1::__unexpected(void (*)()) + 0 > 7 libstdc++.6.dylib 0x956272b8 > __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0 > 8 libstdc++.6.dylib 0x95627658 operator new(unsigned long) > + 101 > 9 libstdc++.6.dylib 0x95627703 operator new[](unsigned > long) + 17 > 10 com.BriTonLeap.convertitmac 0x0000d79e 0x1000 + 51102 > 11 com.BriTonLeap.convertitmac 0x0006be3b > LinkedList<Str>::RemoveAt(__POSITION*) + 1333 > 12 com.BriTonLeap.convertitmac 0x0006cc8b > LinkedList<Str>::RemoveAt(__POSITION*) + 4997 > 13 com.BriTonLeap.convertitmac 0x0002f520 0x1000 + 189728 > 14 com.BriTonLeap.convertitmac 0x0002fc26 0x1000 + 191526 > 15 com.BriTonLeap.convertitmac 0x00022e26 0x1000 + 138790 > 16 com.apple.Foundation 0x95bfc270 _nsnote_callback + 345
So, a Cocoa notification handler method somewhere in your code is calling a C++ method on a LinkedList class, which calls operator new to allocate memory, and that's throwing an exception. (It's probably an out-of-memory exception; that's about the only exception operator new will throw.) There's no 'catch' block anywhere on the stack, so the C++ runtime aborts the process. The top possibilities, in sort-of descending order of likelihood (IMHO) are: (a) The call to operator new is passing a ridiculously huge size that exceeds the amount of free address space. This can infamously happen if the size calculation comes up negative, since the size parameter is unsigned. (b) The process has actually run out of address space (a 32-bit process has between 2 and 3 GB of free space for malloc), maybe due to some terrible memory leak. (c) The process's heap is corrupt, but in such a way that malloc doesn't detect the corruption but instead thinks there's no free space. Why does this only happen in Rosetta? Probably some random factor that triggers the bug when running x86 but not PPC. Maybe the bug depends on little-endian storage, or the particular stack layout... —Jens_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
