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.
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.
Okay, I'm NOT new to Objective-C but I encountered a strange bug, that i have never seen before. Maybe I only made a small mistake and you're able to see it.
Within one of my functions I start by creating a new object from a custom view-class in the following way:
[buttonsBackground removeFromSuperview];
self.buttonsBackground = [[[PostCommentButtonsBackground alloc] initWithFrame:self.contentView.bounds] autorelease];
buttonsBackground.delegate = self;
But if I jump with the debugger over this block, the debugger claims that buttonsBackground would be a nil-pointer. But adding a NSLog right afterwards with
NSLog(#"%#",self.buttonsBackground);
still prints the line
<PostCommentButtonsBackground: 0x7bd27a0; frame = (0 0; 320 82); layer = <CALayer: 0x6e688b0>>
which clearly means, that it can't be nil. Does anybody have an idea how this can even be possible?
I am using the LLDB Debugger, not the GDB. The property buttonsBackground is declared as
#property(nonatomic, retain)PostCommentButtonsBackground *buttonsBackground;
so a missing retain isn't the case either.
EDIT: Okay, I just saw, that i'm not the only person with the exact same problem. There's another person with the same problem Debugger lldb says my object is nil when is not ?
I'm just leaving this post open anyway, because in the other post people kept claiming, the developer did a bad job with his memory management. In my post you can actually see, that this is not the case.
LLDB with the new Xcode 4.3 sometimes is totally lost, and using a NSLog instead of LLDB will show you that your initialized object is correctly initialized and not nil.
So, this is really a pain when you're in front of a bug.
I am getting a crash the second time I attempt to add a certain view as a subview. The crash happens here:
-(void)AddAsScrollableSubContext:(UIView*)view {
[pExtendedScrollableSubContextBounds addSubview: view]; //CRASH HERE
pSubScroll.userInteractionEnabled = true;
}
the second time I call...
[mSongContext AddAsScrollableSubContext:pEQRoot];
The flow is something along the lines of
[mSongContext AddAsScrollableSubContext:pEQRoot];
...Load a lot of stuff
...Press a Button
...Unload a lot of stuff
[pEQRoot removeFromSuperview];
...Press a Button
[mSongContext AddAsScrollableSubContext:pEQRoot];
When I get the bad access the callstack looks like the following:
Both objects (pExtendedScrollableSubContextBounds and pEQRoot) appear to be valid. Adding other subview to pExtendedScrollableSubContextBounds works fine and calling other operations on pEQRoot (subview, frame) also work.
I read the in objsend r0 was the object and r1 was the selector so I looked at the memory address for r1 and saw...
This feels like I am trashing memory somewhere around isKindOfClass: but I am not quite sure. Could anyone point me to more info on iOS obj_msgsend? is there a way I can setup a watch point to catch when this memory trash is occurring?
Use NSZombies to fix the problem.
On a slightly unrelated note, there's a rule of thumb - NARC which stands for new, allocate, retain, copy. If a method call includes any of these keywords, then we have ownership of the object and we are then supposed to release the object.
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.
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.