Meaningless C ++ and Objective-C ++ crash on Mavericks

Question

I have a large Mac application that runs for several days at a time, working on a large dataset. This is a combination of Objective-C ++ and C ++. It works great on Mountain Lion, but on the Mavericks, after working for about 10-20 minutes (in which several million objects were allocated and destroyed), it crashes. It behaves as if it is crashing with an invalid pointer (i.e., it calls a function on a remote C ++ object), but the object it points to is in a state that makes absolutely no sense.

All my C ++ classes inherit from a common base class, where the constructor looks something like this:

MyClass::MyClass() { mCreated = 12345; //int member variable set here and NEVER TOUCHED AGAIN. //other initialization stuff } 

When it crashes, the debugger shows that in a bad object, the value for mCreated is 0. It behaves as if the object never started its constructor!

I don’t think this memory is stomping, because this value is never anything other than 0 or its expected value, and none of the other fields of the object have values ​​that look like garbage that you expect from stomping memory .

I also tried to run using scribble, and the values 0x555 and 0xaaa not displayed anywhere. I also tried Guard Edges.

An in-depth investigation revealed nothing. A bad object is not always the same class. All I can come up with is that something with new memory material in Mavericks (compressing unused memory) causes some kind of new behavior (maybe an error or maybe some previously unknown, mostly unmanaged rule which really matters).

Has anyone seen something like this? Or does anyone know any fundamentally unknown memory rules that will apply more strongly under Mavericks?

Answer 1

I think you are right in a suspicious suspicious pointer. It can be a pointer to a remote object or it can be a garbage pointer. Any of these will correspond to the mCreated member, which is different than expected. In the case of a remote object, the memory can be used for something else and therefore set to some other value. In the case of a garbage pointer, you are not indicating what has ever been an instance of your class.

I don't know how well the Allocations tool works for C ++ objects, but you can try to reproduce the crash while doing this. When it stops in the debugger, get the this pointer, and then get the history of this address from the tools.

If the Tools do not work, you can set the environment variable MallocStackLoggingNoCompact . Then, when it stops in the debugger, examine the this pointer and use the following commands to view the history of this address:

 (lldb) script import lldb.macosx.heap (lldb) malloc_info --stack-history 0x10010d680 

(Use this address instead of 0x10010d680 , of course.)

Alternatively, you can use the malloc_history command from the shell to examine the history if it is cumbersome to do in LLDB.