XCode debugging skills-BUG solving in EXC_BAD_ACCESS

XCode debuggingTip: EXC_BAD_ACCESSBUGThe solution is described in this article. During iphone development, EXC_BAD_ACCESSBugIt is not easy to find the cause. I found three methods on the Internet to help you with this problem. I tried the method in the first step, and the effect was good.

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.

1. Override the respondsToSelector method of the object. In reality, the last object accessed before EXEC_BAD_ACCESS appears.

Sometimes the program crashes without knowing where the error occurs. For example, when EXEC_BAD_ACCESS occurs in a program, although the NSZombieEnabled environment variable can be used in most cases to locate the problem, in a few cases, even if the NSZombieEnabled environment variable is set, I still don't know where the program crashed. You need to use the following code for help:

 
 

  
  
 #ifdef _FOR_DEBUG_  
  
  
-(BOOL) respondsToSelector:(SEL)aSelector {  
  
  
    printf("SELECTOR: %s\n", [NSStringFromSelector(aSelector) UTF8String]);  
  
  
    return [super respondsToSelector:aSelector];  
  
  
}  
  
  
#endif  
 
 

You need. m or. add the above Code to the mm file, and add-D _ FOR_DEBUG _ to other c flags. Remember to add this flag only under Debug Configuration ). In this way, when your program crashes, the Xcode console will accurately record the method of the last running object.

2. Use NSZombieEnabled

I believe many people know that NSZombies is used to help debug EXC_BAD_ACCESS, but sometimes the required information cannot be found. What should I do?

The following is an example of the hello world code:

 
 

  
  
NSString* hello = [NSString stringWithFormat:@"Hello world"];  
  
  
NSLog(@"What you say is %@",hello);  
  
  
[hello release];  
 
 

After running, the EXC_BAD_ACCESS error occurs. But no other prompts are displayed. In this case, right-click the application name under executables, select get info, and enter the environment variable (NSZombieEnabled, MallocStackLogging) in arguments)

After running the program again, click zoom in)

This time we can see that the problem is "message sent to dealloced object", but we still don't know which statement caused it. Therefore, we need to enter the following statement on gdb:

 
 

  
  
shell malloc_history pid address 
 
 

So What Are pid and address? Let's take a look at the crash image and use the following command to quickly determine where the pid and address come from. My command is:

 
 

  
  
shell malloc_history 596 0×5f3ef80 
 
 

When the program is run again, a large amount of stack trace information will appear during the crash process, such:

Based on this information, you can find the problem that occurs in [BadAccessViewController viewDidLoad] and is related to + [NSString stringWithFormat.

Finally, remember to delete or set the environment variables NSZombieEnabled and MallocStackLogging to NO, because they will prevent the memory from being released.

3. Set a Global breakpoint to quickly locate the row of the problematic code

XCode debugging tips-set a Global breakpoint to quickly locate the row of the problematic code [zz]

Summary:XCode debuggingTip: EXC_BAD_ACCESSBUGThe solution is complete. I hope this article will help you!