How to debug "message sent to freed instance" in Xcode4?
I pressed ALT + CMD + R and activated NSZombieEnabled in Arguments> Environment Variables. In addition, I activated it under Diagnostics> Memory Management> Enable Zombie Objects.
However, when I created and started, at some point, my application crashed this useless message to me in the console:
*** -[CALayer retainCount]: message sent to deallocated instance 0x656b260 A stack trace is just as useless. I moved the slider of the level of detail all the way to the right. Topic 1 just shows me this:
Everything belongs to the system and there is not a single line related to my application. So, obviously, NSZombiesEnabled does not work like in Xcode 3, where it stopped on a dead object.
Is there any way to find out which CALayer is released too soon?
Update: therefore, after creating and starting another 100 times, suddenly the DISAPPEARED problem! He is completely gone! And the best part: I did not change my code in any way! In the interval, I cleaned the build folder several times and projected clean commands and deleted the application several times in the Simulator.
Update 2: Fortunately, the problem reappeared. And now it seems persistent. Fortunately, because I prefer to find the root cause rather than annoy users randomly.
Update 3: Finally, it happened by accident:
startButton = newBttn; should have been:
self.startButton = newBttn; startButton was a persistent property, and in -dealloc I released it. Thus, it was renamed and in most (but not all) cases after the look disappeared, it crashed, giving this strange message CALayer keepCount.
The Zombie Tool (CMD + I) finally indicated that it is associated with a button. I just did not know why and where.
The Clang static analyzer did not complain about this apparent glitch.
If this reappears, you can run the special Zombies tool. Hit Command + I to profile the application and select the Zombies tool (you have to work on the simulator). If you get zombies, you can display the entire memory history (each save / free) for this object, which is very useful when tracking errors.
In addition to Jeff, a great answer; to do almost the same thing, but without having to open the tools or profile of your application, you can install NSZombieEnabled , MallocStackLogging and guard malloc in the debugger. Then, when your application crashes, enter it in the gdb console:
(gdb) info malloc-history 0x543216 Replace 0x543216 address of the object that caused the crash, and you will get a much more useful stack trace, and this will help you pinpoint the exact line in the code causing the problem.