iOS Development--Debugging Tips OC Chapter &exc_bad_access everywhere

Exc_bad_access everywhere

This kind of error can be said every time you write code will encounter, so if it is you how to solve, if you do not know then please look down

Exc_bad_access, Objc_msgsend,

This kind of error often comes momin wonderful.

The reason is often memory over-release caused, that is, write more release;

As to where to write more release, it is difficult to find out, the following and for the query method.

This occurs, that is, the excessive release of the pointer object, causing the secondary pointer to the wild pointer error , (note:[nil release] operation NULL pointer is not error, there is a problem in Java , [wild pointer Release] Error crash is very dangerous , to solve the bug, there are many, briefly the following several simple:

one: In Xcode, run,stop to the right is where you select the device to the left to findScheme >edit scheme>arguments>environment variables under add 1. Nszombieenabled YES2. MallocstackloggingnocompAct YES 3. mallocstacklogging YES





> OKFirst, let the system print out the wrong address.
The second allows Xcode to record the history of each address alloc, so that we can restore the address with a command The third can open the Mallocstack and know the history of memory being configured in the program . (Note: This command only supports GDB, the output of the console must be changed to GDB, only the emulator is supported, not the real-machine debugging)
Two: Add print in. m or. mm files The last log file code is as follows:

#ifdef_FOR_DEBUG_

-(BOOL) Respondstoselector: (SEL) Rtselector

{

nsstring *classname =nsstringfromclass ([Selfclass]);    

NSLog (@ "%@-->rtselector:%s", Classname,[nsstringfromselector (Rtselector) utf8string]);

return[superRespondstoselector: rtselector];

}

#endif

Three: Find the blurred place, breakpoint debugging, or print the logo from a wide range to a small range,

Specific operation I will not say much here, according to the needs of the project to the left of the corresponding code line to click on the point can be interrupted

Four: the way of leak

2. Open the Instruments tool:

   Xcode--Open Developer Tool--Instruments,

   Select the Zombies type.

4. Restart run project and do not go to the crash point.

   Choose the name of the program to be checked in the open instruments tool;

   Then click the Record button in the upper-left corner of instruments to start recording memory usage.

6. Continue execution of the program to the crash point.

   The program executes to the 40th second to report the zombie messaged error;

   Click on the ">" in the circle to see the memory details.

8. Parsing Memory Invocation Details:

   Exclude the operating system retain, release part,

   It is because Cameraliveviewcontroller executes Dealloc,

   The release is called More 0x180d5420 memory.

10. Combine the above results:

    It is known that one of the uilabel that exists in the Cameraliveviewcontroller has performed the release more.

    You can add code to the suspicious Uilabel print log in Cameraliveviewcontroller.

    Re-execute the above procedure and compare the address of the printed Uilabel and Zobmie memory,

    To locate the error location.

iOS Development--Debugging Tips OC Chapter &exc_bad_access everywhere