Ios5.0 does not have an automatic application counting mechanism, nor does it have garbage collection functions like Java. We all need to manage and control the collection of objects by ourselves. This is a very troublesome task and the most common problem in IOS projects. If you do not master these methods, there is almost no clue about debugging these problems.
1. exc_bad_access memory error and nszombieenabled
Exc_bad_access is the most common error, which is generally caused by access to the released memory address space. For example, if an object has already been dealloc and you still send messages to this object, this error will occur. Since this error hardly displays any useful information, we cannot determine where the program is wrong. The nszombieenabled environment variable can solve this problem well.
Open your project, select "product-> edit Scheme" or press the shortcut key "Commend + <"
The nszombieenabled environment variable keeps the released memory object information. If we send a message to a released object, we will get an error message, in addition, the program automatically breakpoint to the error location. If we send a description message to a released uibutton object, the following message is displayed on the debugging terminal:
*** -[UIButton description]: message sent to deallocated instance 0x1580f360
In this case, the program will automatically breakpoint to the "[uibutton description];" line of code.
2. overrelease and mallocstackloggingnocompact appear in the framework object.
Through nszombieenabled environment variables, we can have a lot of bugs. But sometimes the error occurs inside the framework, and the current stack of the breakpoint is not in our code. For example:
xxx: *** -[CALayer release]: message sent to deallocated instance 0xe250df0
This calayer is not directly created, and the release message does not occur in our code. We do not know that this calayer is the view. Therefore, it is hard to clarify that the class has a problem. If you know where the calayer is located, alloc is ready. Then we need the mallocstackloggingnocompact environment variable. This environment variable enables the alloc log, which records the stack situation of each object alloc. Based on the stack situation, we can find out that class initializes this layer and then check the code to solve the problem. The setting method is similar to that of nszombieenabled:
When the message sent to deallocated instance message is generated, enter:
info malloc-history 0xe250df0
It will print the stack situation during layer alloc. You can see the code call situation, find our own code, check the code and modify it.
From: http://xcodev.com/wordpress? P = 209