On CCLabelBMFont, I get a EXC_BAD_ACCESS on its dealloc method. Specifically, line [configuration_ release];
I do not understand that at all. What could possibly cause that? My CCLabelBMFont was created alright, displayed alright, and when it is dealloced (when the scene is replaced), bang, the error comes.
Ideas?
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
Related
I am getting a crash on my app. It's occurring on dismissModalViewControllerAnimated: message, but... if I set a breakpoint on the NSLog, and step over, it goes through with problem, the EXC_BAD_ACCESS code is 2 and address 0x4:
Thread 1: EXC_BAD_ACCESS(code=2, address=0x4)
I've never had something work with breakpoints and EXC_BAD_ACCESS without them, any ideas?
Please note that my appController is fine. (not released anywhere).
if (appController.modalViewController) {
NSLog(#"==== RETAIN COUNT ====> %d", appController.modalViewController.retainCount);
[appController.modalViewController dismissModalViewControllerAnimated:NO];
}
Retain count logs to 1
This also ONLY happens for iOS 4.2 and my app is running on iPad only
retainCount is useless. Don't call it.
If you have a crash, you have a backtrace. Please post it.
I've never had something work with breakpoints and EXC_BAD_ACCESS
without them, any ideas?
Generally indicates a race condition; your code is dependent on thread A finishing or not finishing something before thread B hits some particular state. Need the backtrace.
I have a window and a window controller which opens when the user clicks a button.
Sometimes I get EXC_BAD_ACCESS(code=1, address=0x0).
0x7fff6f2a59e0: movq (%rax), %rdi
Here is the code:
ChooseProceduresWindowController *chooseProceduresWindowController = [[ChooseProceduresWindowController alloc] initWithWindowNibName:#"ChooseProceduresWindow"];
[NSApp runModalForWindow:[chooseProceduresWindowController window]];
The error appears then runModalForWindow: is called.
I don't get this error every time, but I couldn't find a pattern.
Thanks
the best way to debug EXC_BAD_ACCESS errors is to use NSZombies.
Check out this video for an explanation :
http://youtu.be/LQtPr8bkB3g
NSZombie keeps all your objects in memory when you are trying to release an object that has already been released, so you get closer to finding your bug. As #Mark H said, it is a memory management issue.
Also you could put an NSLog in your dealloc method to have a better idea of what is getting deallocated when at runtime.
That error will be thrown when the object doesn't exist in memory. I'd start looking for memory management issues. The first would be to make sure you are releasing the ChooseProceduresWindowController after using it.
I have a simple UITableView application that I just converted to ARC. The conversion supposedly went fine, and the app launches now, but if I navigate into a DetailView, then try to jump back to the RootView, I get a BAD_EXC_ACCESS error in main.m, and a crash. I tried turning on Zombie objects, and that stops the crash, but I also don't get anything in the console telling me what was happening. I turned off ARC, and again, no crash, but also no more info on what was causing it in the first place.
Any ideas on how to debug this would be greatly appreciated.
BAD_EXC_ACCESS are a little tricky, mainly because they don't show up at the offending line which causes the error. Using lldb, you can use thread backtrace to get an idea of what is causing it. This answer contains a great answer with a few ideas on how to troubleshoot similar problems.
I enabled the nszombie in xcode 4.2. (from product->editScheme)
I have got this message:
-[buttons respondsToSelector:]: message sent to deallocated instance 0x48ae50
I do have buttons class, but i dont see what the exact problem by this message.
can i get more from the NSZombie ?
The problem is that an object of type buttons was deallocated and then it's respondsToSelector: method was called, that object is at address 0x48ae50.
If you were running without NSZombies your application would have crashed.
What this specific message means is that the buttons instance (at 0x48ae50) has been deallocated (a.k.a. released). So, by trying to send the respondsToSelector: message to nothing (remember the instance has been de-alloc'd), it throws an error.
Try setting a breakpoint near the place where it's being triggered and see why... (for now, your buttons object will most like have an address of 0x0)
In most (if not all) cases, this has to do with some faulty memory management; an object being released too soon, not retained when it had to, etc... ;-)
I'm getting an EXC_BAD_ACCESS with my iPhone app on 0x01ad809b <+0015> mov 0x8(%edx),%edi
I have NSZombieEnabled set to YES but I'm not seeing any class printed out in the debugger like I normally do.
Is there another way to debug this problem?
You have a crash caused, most likely, by corruption of memory, using a variable that isn't initialized, and/or casting a non-object type to an object.
First, post the backtrace of the crash. That will provide more context.
Second, try Build and Analyze. Fix any of the problems that it identifies.
Finally, if this is a new crash, go back to a revision right before the crash and then roll forward until you hit the crash. What are the changes made over that span of time?
With more context -- the crash log, in particular (or backtrace, at the least) -- more specific debugging techniques can be offered.
You can select Breakpoint navigator and add breakpoint on all exceptions. Maybe it will help.
Try with malloc info as well.
Use Instruments to Profile and detect zombies instead.
Change the build target to the Simulator
In the Build menu, select Profile
Instruments will open, then select the Zombies instrument
This automatically sets up the NSZombieEnabled flag and will popup a message whenever a dealloced object is messaged. Clicking the disclosure will show the memory management events of the object.