Unable to find Zombie in Instruments for device .
I am able to find Zombie in Instruments for Simulator but not able to find for device , my app only run on device due to addition of third party api.
How can i trace cause of crash due to "message sent to deallocated instance "
I just want to find exact instance(or line of code) which is causing this crash.
Although, when XCode returns "Message sent to deallocated instance" error message, it normally tells the Object as well which is sending that error.
Anyway, you can use the below to find the exact line which is causing you the error:
Use Exception BreakPoint for All Exceptions in XCode.
To Add an Exception Breakpoint:
1. Go to BreakPoint Navigator
2. At the bottom there is a plus symbol. Click it.
3. You will get two options: Add Exception Breakpoint... and Add Symbolic BreakPoint...
Choose Exception Breakpoint.
Some reasons for zombies crash:
1. Control delegate response late after the control instance is cleared.
2. Instance used inside the thread try to modify the instance after its get cleared.
So handle the delegate properly
Make control delegates to nil while removing view controller like this:
- (void)viewDidDisappear:(BOOL)animated
{
[self.mapView setDelegate:nil];
[_webView setDelegate:nil];
}
Related
UPDATE
This is an old question for an old version of Xcode. It turned out that the issue was a bug in Xcode which has been fixed.
Original
I have a storyboard generated from making a new tab iphone application (with ARC)
In one of my tabs, if I drag a gesture recognizer (any, but let's say Pan) onto a control, and then set the selector to an action, it just crashes as soon as I go to the tab.
There is nothing in the Console -- it appears to be happening while the storyboard is being loaded (viewDidLoad is never called).
I can't figure out how to get more information
On a different tab, this works fine. Both tabs were generated automatically.
(it's possible I messed something up in the view, but I don't have a clue to figuring out what I did).
If I make gestures programmatically, they work fine, but it's nice to have it work in the storyboard, and I'm afraid that whatever is wrong will cause a crash some other way at some point.
MORE INFO
In the simulator I get
-[__NSCFString setView:]: unrecognized selector sent to instance 0x6d2db70
Again, need debugging techniques -- for example, is there a way to find out what object 0x6d2db70 is?
Which is exactly like this question (with no answer):
Gesture recognizer in Interface builder crashes my app
MORE INFO
This is trivial to reproduce
New iPhone tabbed application, ARC and Storyboard on
Drag tap gesture onto second tab's view (works on first one)
Create an (IBAction)
Connect the gesture's selector connection to the action from #3
run, go to second tab
Crashes. Same thing with my app, default tab works, other tabs don't
The error message tells us that the program is sending the setView: message to an instance of __NSCFString (which is obviously the private implementation class of NSString).
Make sure you have tried running with zombies enabled. A zombie can easily cause an unrecognized selector error.
If it's not a zombie, put a breakpoint on -[NSObject doesNotRecognizeSelector:]. When the breakpoint is hit, you may be able to figure out the problem just from the stack trace. If not, you can print the debugDescription of the object (which is the same as the description for most classes).
On the simulator, you can ask the debugger to print the object's debugDescription like this:
(gdb) frame 0
#0 0x013bcbff in -[NSObject doesNotRecognizeSelector:] ()
(gdb) po ((int*)$ebp)[2]
this is my test string
On the device, you do this:
(gdb) frame 0
#0 0x344bca22 in -[NSObject doesNotRecognizeSelector:] ()
(gdb) po $r0
this is my test string
Update
Based on your steps to reproduce, this is a bug in UIKit. File a bug report. You can work around the bug by creating a strong outlet on SecondViewController and connecting it to the gesture recognizer. Make sure you set the outlet to nil in viewDidUnload.
Update
Do not ever set your outlet to nil -- part of the bug is that UIKit isn't retaining -- you need to keep your reference to make sure that the recognizers aren't released.
In my case, when auto-creating the IBOutlet for the gesture recognizer by drag-n-dropping in the code, Xcode correctly created the property with a "strong" attribute, but it also added the "set to nil" in viewDidUnload. Removing the "set to nil" solved the issue for me.
In my App I have an UIViewController, that pushed by another ViewController's navigation controller. It contains some views, buttons, scrollViews and accelerometer support. When I tapping "back" button of navigationController, app crashes without any log message, except this one:
"warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.3.3 (8J2)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).
(gdb)"
debugger links me to this line in main.m:
int retVal = UIApplicationMain(argc, argv, nil, nil);
with "EXEC_BAD_ACCESS"
what does this mean?
EDIT:
all of you are right.
problem was in accelerometer. I setted delegate ([UIAccelerometer sharedAccelerometer].delegate = self;) and didn't remove it. that's why there was no line in my code for debugger to link to. I just added this:
- (void)viewWillDisappear:(BOOL)animated {
[UIAccelerometer sharedAccelerometer].delegate = nil;
}
and problem gone. So, If you are using any device functions, be careful with delegates.
Did you set Zombies to enabled? That will enable you to track if you access an already released object, and that tells you which object it is.
If you are using XCode 4, you can enable zombies in Project -> Edit Scheme -> Diagnostics by checking the "Enable Zombies" checkbox.
Also make sure you have "Break on Exception" set on - in XCode 4 go to the Breakpoint View, press the Plus sign in the lower left corner, and choose "Add Exception Breakpoint ..." for all exceptions. Then XCode will break at the point where the exception occurs, and you will see more than just UIApplicationMain as the location.
This means you have tried to read/write a block of memory you have no permission to. Maybe you're trying to use an object you haven't allocated/initialized. Check your code, debug it and inspect variables to find a solution.
I guess you had a memory warning and you app deallocated some datas tha are not there anymore when you go back.
Put some breakpoint into didReceiveMemoryWarning, dealloc, viewDidUnload and viewDidLoad to see what happens in your previous controller.
EXC_ BAD_ ACCESS is an exception (EXCeption_ BAD_ ACCESS).
If you set a breakpoint on objc_exception_throw (sign + on the lower left corner of debug tab), you'll get those.
You might want to look at NSZombieEnabled (http://www.cocoadev.com/index.pl?NSZombieEnabled), as you're probably trying to access a dealloc'd object.
My program will crash if I press the segmented control buttons one after another. For example, if i press the first one, then second, and third, it will crash. Any ideas for what could be causing this. I also release it and everything, really stumped here. Any ideas.
Thanks
- (IBAction) segmentedControlIndexChanged {
switch (self.segmentedControl.selectedSegmentIndex) {
case 0:
[self mirror];
break;
case 1:
[self exact];
break;
case 2:
[self round];
break;
}
}
I'm getting a EXC_BAD_ACESS
if that means anything, cause i'm not sure what that means
error on line 2179 of "/SourceCache/gdb/gdb-1510/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
EXEC_BAD_ACCESS means you are attempting to call a method on a deallocated instance. The tricky thing about fixing these errors is that it can happen well after the instance was released, so what you're doing at the time isn't necessarily what is causing the error.
Fortunately, there is a tool to help you. NSZombieEnabled
Go down to your executables folder in XCode, and right click on the app and click Get Info.
Go to the Arguments Tab, and click the plus button below variables to be set in the environment.
Call the new variable NSZombieEnabled and set it's value to YES
When you enable this, any instance that gets deallocated gets replaced by a Zombie object, and your console should display an object and "message sent to deallocated instance" which should help you track down your problem.
So I have a subclass of a UIView that starts causing EXC_BAD_ACCESS errors when I go through a specific set of conditions (run on iPad instead of iPhone or simulator, first login only). It throws the exception when the UIView subclass gets autoreleased from the pool (i.e. the pool is releasing, not when I'm calling [view autorelease], during the last line, where I have [super dealloc]. I heard about using NSZombieEnabled, so I tossed that on to see if I could get any more information about it, but now it hides the error completely!
Does anyone know a bit more about this type of situation? I thought NSZombie would start spewing stuff into my console like before, but I'm hoping that the nonexistance of errors would tell me some sort of information as well.
- (void)dealloc
{
[loadingLabel release];
[indicatorView release];
[super dealloc];
}
Edit: Ok, so I sorta solved the underlying problem:
One of my properties was:
#property (nonatomic,retain) NSString * title;
However, the code for that property is as follows (loadingLabel is a UILabel):
- (void)setTitle:(NSString *)title
{
loadingLabel.text = title;
[loadingLabel sizeToFit];
[self setNeedsLayout];
}
- (NSString *)title
{
return loadingLabel.text;
}
I don't actually retain anything, but rather only do a UILabel.text, which is a copy property. So I changed my own title property to reflect this, and the error has disappeared.
However, I still don't really know how or why this error popped up in the first place, and why it only appears on the iPad platform (not the iphone, or even the ipad simulator).
So I have a subclass of a UIView that starts causing EXC_BAD_ACCESS errors when I go through a specific set of conditions (run on iPad instead of iPhone or simulator, first login only). It throws the exception when the UIView subclass gets autoreleased from the pool (i.e. the pool is releasing, not when I'm calling [view autorelease], during the last line, where I have [super dealloc]. I heard about using NSZombieEnabled, so I tossed that on to see if I could get any more information about it, but now it hides the error completely!
You get EXC_BAD_ACCESS because you tried to work with a dead object.
NSZombieEnabled makes objects not die. Since the object never died, your app didn't crash. Instead, you'll get a message in the Console log (the Debugger Console when running under Xcode), telling you what you did wrong and suggesting a breakpoint to set.
To be more specific, the NSZombie message will tell you what class of object you sent a message to, and what message you sent it. If you set the breakpoint and run your app with the debugger active, the debugger will interrupt (“break”) your app at that point, so that you can look around and see what sent the zombie object the message.
I don't actually retain anything, but rather only [assign to] a UILabel.text, which is a copy property.
Thus, the string presumably died off for not being owned by anything. With NSZombieEnabled and the above technique, you can confirm the theory that it was the string that was dying off prematurely.
A better and easier way, though, is to use Instruments's Zombies template. Instead of a message appearing in Xcode's Debugger Console, a flag in will appear Instruments's timeline with the information. That flag will have a go-to-iTunes-Store (➲) button you can click for more information about the problem.
Could you clarify - do you mean that you throw an EXC_BAD_ACCESS exception or you (on purpose) cause the system to throw an EXC_BAD_ACCESS exception? How do you do this? Please show some code. NSZombie will spew to the console if you try to call an instance method on it. Are you doing that?
NSZombie should produce output to the console in the same location a crash would have occurred.
Have you tried also running Instruments with the ObjectAlloc tool, and enabling both retain count and zombie detection in there (you need it both in the executable and configure the ObjectAlloc instrument, click on the "i" next to ObjectAlloc). When a message is sent to a zombie that instrument will flag you with a special popup saying a zombie was detected.
Remember the iPad SDK is still beta, maybe you should report this but to apple if you can confirm this to be a bug. Unfortunately their bugtracker is horrible from my experience.
The behavior of NSZombie is to never decrease an objects retain cound if release is called. However it keeps track of the would-be retain count and logs acess to the object after it would have been deleted on the console. It puts the Object adress alongside the error message, together with Instruments you can easily locate the Object at that adress and determine where it has been alocated and who retained/released it.
Apple Developer Reference Library has a class reference for WebPreferences
I've searched SO, Dev Forums and Googled without any relevant results.
EXC_BAD_ACCESS signal is generated.
I can't find a crash report.. its happening on the simulator. The debugger is called, and I don't get a crash report.
EDIT
This is triggered when tapping a UITextField, leaving a UITextField or if a UITextField is set as first responder when loading a view (push on by a navigation controller).
It is not easy to reproduce. I can go for a hundred app-launch/debug cycles before it will happen again. And then it might happen 3 times in 5 launches.
I do have a thread list in the debugger that shows several references to WebPreferences.
You're on the right track if you are using NSZombie. EXEC_BAD_ACCESS is caused by accessing released objects.
It is normal for EXEC_BAD_ACCESS to "crash" in code paths that do not belong to you. Most likely your code created the over-released object.
The key part of using NSZombie is running the malloc_history on the command line. You'll get the call stack showing where the over-released object originated from. For example:
alt text http://static.benford.name/malloc_history.png
The screenshot shows my app crashing at [NSString stringByTrimmingCharactersInSet:] but that is certainly not who caused the crash.
I technique I use is to look at the earliest code path that you own. Most of the time the mistake lies there.
In this case, the object originated from the class [JTServiceHttpRequest requestFinished], in which I was not properly retaining a object.
If all else fails, go through all your code paths listed and verify your use of proper memory management rules.
My bet is that WebPreferences and UITextField behavior have nothing to do with the crash.
For any EXC_BAD_ACCESS errors, you are usually trying to send a message to a released object. The BEST way to track these down is use NSZombieEnabled.
This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.
It especially helps in background threads when the Debugger sometimes craps out on any useful information.
VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever released, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
NSLog(#"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
If you need help finding the exact line, Do a Build-and-Debug (CMD-Y) instead of a Build-and-Run (CMD-R). When the app crashes, the debugger will show you exactly which line and in combination with NSZombieEnabled, you should be able to find out exactly why.
The fact that it's crashing in _integerValueForKey: makes me strongly suspect that it's crashing on an over-released NSNumber. Over-releasing an NSNumber can lead to such bizarre crashes that it's almost humorous. Here's what happens:
You create a NSNumber for the integer "2"
The NSNumber class caches the NSNumber
You over-release it
The NSNumber class's cache now points to bad memory
Some completely unrelated piece of code creates an NSNumber for the integer "2"
The NSNumber class looks it up in its cache, and....
Bang
If you're running Snow Leopard, hit Cmd-Shift-A to let the analyzer look for memory management problems. Otherwise, go hunting in your use of NSNumbers.
agreed with previous responders about NSZombie. Most often this thing happens when you use your class as a delegate of a UITextView(or any else class) and also refer it in IBOutlet variable. when you leave your viewcontroller - it become deallocated. but if you didn't release IBOutlet variable in - (void) dealloc method - UITextView will still send calls to released delegate (your view controller).
Sounds more like an Auto-Release bug. You might be releasing something you don't "own" and the NSAutoRelease pool is running and trying to clean up something that was already released?
Did you release something you didn't "alloc"? For example, you wouldn't do:
NSString *test = #"testing";
[test release];
As this will cause the crash to happen when the Auto Release pool runs and attempts to release the NSString.