Thread 1 : EXC_BAD_ACCESS (Code = 1, address = 0x30000008) issue generated

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

EXC_BAD_ACCESS occurring at objc_msgSend in Thread 1.

  • iOS SQLite.swift, regarding upgrade of app?
  • passing objective c variable to javascript in ios
  • Remove back arrow in iOS7
  • Xcode 6 Standard architectures exclude armv7s
  • Create grouped UITableviewCell with custom selection Color and Border
  • Which conditional compile to use to switch between Mac and iPhone specific code?
  • Screenshot :

    enter image description here

    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.

    3 Solutions Collect From Internet About “Thread 1 : EXC_BAD_ACCESS (Code = 1, address = 0x30000008) issue generated”

    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()

    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.

    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.