Thread 1 : EXC_BAD_ACCESS (Code = 1, address = 0x3

问题:

I have an issue running an app on a simulator. The problem:

EXC_BAD_ACCESS occurring at objc_msgSend in Thread 1.

Screenshot :

In my Application, I have multiple ViewController. when I click on back button of UINavigationBar then this type of issue is generated, I can't explain my problem because all the functionality works properly.

Example :-

1 - fitstVController (work properly)

=> it have UITableView, when I click on specific row then it will go on another UIViewController (SecoundViewController)

2 - SecoundViewController (work properly)

=> it have UITableView and UIActionSheet. when I select button of UiActionSheet then another UIViewController (ThirdViewController) is open

3 - ThirdViewController (work properly)

=> it have UITableView and multiple UIPickerView. But HERE IS PROBLEM THAT I CAN'T GO BACK AT PREVIOUS UIViewController (SecoundViewController). => when i do that then EXC_BAD_ACCESS (Code = 1, address = 0x30000008) issue generated.

回答1:

In short, this type of problem occurs when you release the memory assigned to an object that has been already released. Most likely, this type of issue is generated when you go back to your previous UIViewController (or other cases).

And also, I suggest reading the following link for a more thorough explanation:

Hamster Emporium archive:So you crashed in objc_msgSend()

回答2:

Setting an exception breakpoint means that Xcode will stop execution as soon as an exception is raised. It's not entirely foolproof, but this will usually result in the app breaking on the line of code that caused the problem.

That makes it a LOT easier to track down the source of the problem - although the stack trace is the definitive way of diagnosing issues, it's often far too detailed to be of much use (especially if like me you're not a compiler expert.)

To set this up, click on the Breakpoints symbol in the Navigator panel and click the + button at the bottom. Then select Add Exception Breakpoint, and Objective-C from the List of choices.

回答3:

As @TimD has rightly pointed out, you can set an exception breakpoint and it will highlight the offending line of code (rather than trying to decipher the assembler or manually trying to identify where the problem is). And, as always, when diagnosing these sorts of memory issues, you should always enable zombies. Finally, especially important in non-ARC code, you should run your code through the static analyzer as many memory related problems can be identified there. You should always make sure you have zero warnings from the static analyzer as it invariably points out critical programming errors.