In iOS development, the most depressing thing is that the program crashes without warning. Using the bt command to call the stack gives a bunch of system EXC_BAD_ACCESS information, and there is no way to locate the problem. First, let's talk about the EXC_BAD_ACCESS error. It can be said that the 90% error is caused by the release operation on a released object. Let's take a simple example. First, let's look at a piece of Java code:
Copy codeThe Code is as follows: public class Test {
Public static void main (String [] args ){
String s = "This is a test string ";
S = s. substring (s. indexOf ("a"), (s. length ()));
System. out. println (s );
}
}
Generally, such a crash occurs because the released memory space is called, or the address space is released again. How can we locate this address? You can edit xcode's scheme and add the following mark bits so that the system can print out the error address,
(Choose Product> Scheme> Edit Scheme to go to the following editing page, select the Arguments tab, and add the bits NSZombieEnabled to YES)
In this case, the system displays the following prompt when a crash occurs:
2013-06-23 00:45:20. 479 ***-[_ NSArrayM addObject:]: message sent to deallocated instance 0x7179910
The cause of the crash is the memory address.0x7179910 is released again.
The Objective-C code has three fatal problems: 1. Memory leakage; 2. Release of errors; 3. EXC_BAD_ACCESS error.
If the crash occurs in the current call stack, the system will locate the cause of the crash to the specific code through the above practice. However, if the crash is not in the current call stack, the system can only tell us the crash address, but cannot locate the specific code, so that we cannot modify the error. In this case, you can modify scheme to allow xcode to record the history of each address alloc, so that we can use the command to restore this address. (Follow-up settingsNSZombieEnabledAddMallocStackLoggingNoCompactAnd set it to YES)
In this way, when the cause of the crash isMessage sent to deallocated instance 0x7179910, we can use the following command to restore the memory address:
Info malloc-historyZero x 7179910
, This command can specifically restore the code generated for this address.
(Note that this command only supports gdb, so you must change the console output to gdb. Unfortunately, it only supports simulators and does not support real-machine debugging)
(SimilarlyChoose Product> Scheme> Edit Scheme to go To the Edit page and select the Info tab.)
In this way, check the line of code and it is easy to find out the problem.