Re: Rosetta Quandry
Re: Rosetta Quandry
- Subject: Re: Rosetta Quandry
- From: David Blanton <email@hidden>
- Date: Tue, 2 Feb 2010 23:03:17 -0700
Jens-
Your narrative of the stack is spot on.
I tracked this down to a node allocation in LinkedList setting is data
value to a string of type Str from a lib I use (I compile it, have the
source). With this lib I have found problems with ownership of chc
buffers. I modified the =operator that was being called to set the
node value so that in the RemoveAt we remove something we own.
Haven't tested this on 27" iMac yet, will do so tomorrow.
One clarification. This error occurs with Rosetta off, setting
Rosetta on allow the program to run. I am highly suspect of the 27"
iMac since Apple has done two firmware update, held shipment for three
weeks at on time, and I only get this error on three customer's 27"
iMacs.
-db
On Feb 2, 2010, at 10:52 PM, Jens Alfke wrote:
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 (email@hidden)
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:
This email sent to email@hidden