EXC_BAD_ACCESS in main () with ARC but does not hint at an error

Question

I'm running out of ideas. I get EXC_BAD_ACCESS in a project using ARC. According to the debugger, it is within main() . NSZombieEnabled is set to YES, but I don't see any call, class or type, or anything else. The same goes for the inspector / profile. All I get is a "session timeout" some time after the application crashes.

And hard to find in my code.

I set up tracks like

 NSLog(@"CrashLog: <%@:%@:%d:%s>", NSStringFromClass([self class]), NSStringFromSelector(_cmd), __LINE__, __FILE__); 

all over my code on enty and exiting methods, but I haven't defined any useful template yet. All I see is that all my methods were left already when throwing EXC_BAD_ACCESS .

Any idea on how to isolate the problem?

Tim suggested using backtrace (bt) in gdb. Result:

 #0 0x0be87580 in TI::Favonius::BeamSearch::choose_hit_test_node () #1 0x0be87b5f in TI::Favonius::BeamSearch::update_for_touch () #2 0x0be8ee32 in TI::Favonius::StrokeBuildManager::update_search_for_touch () #3 0x0be8f58f in TI::Favonius::StrokeBuildManager::key_down_or_drag_hit_test_for_UI () #4 0x0be6ba8b in TIInputManagerZephyr::simulate_touches_for_input_string () #5 0x0be7e5d9 in -[TIKeyboardInputManagerZephyr candidates] () #6 0x00678345 in -[UIKeyboardImpl generateAutocorrectionReplacements:] () #7 0x007dcaec in __71-[UITextInteractionAssistant scheduleReplacementsForRange:withOptions:]_block_invoke_0 () #8 0x007f6db2 in -[UITextSelectionView calculateAndShowReplacements:] () #9 0x00e255fd in __NSFireDelayedPerform () #10 0x01a03976 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ () #11 0x01a03417 in __CFRunLoopDoTimer () #12 0x019667e0 in __CFRunLoopRun () #13 0x01965dd4 in CFRunLoopRunSpecific () #14 0x01965ceb in CFRunLoopRunInMode () #15 0x01ccb879 in GSEventRunModal () #16 0x01ccb93e in GSEventRun () #17 0x0050d38b in UIApplicationMain () #18 0x000033e0 in main (argc=1, argv=0xbffff5fc) at /Users/Hermann/AppDev/fcApp/fcApp/main.m:16 

Answer 1

There are still ways to get EXC_BAD_ACCESS with ARC. Some I encountered

• If you do something where you create an object and it will call you back asynchronously, you must be sure that you will refer to it somewhere, or ARC will release it. For example, UIImagePicker - you cannot just make a local image selection variable and call it (and then release it when it calls you back) - you need to make the property and hold it

• If you do not always use properties to hold it, you may run into problems - ARC uses the presence of strengths and weaknesses to know what to do - if you use ivar instead, you can trick ARC (not 100% sure about this) . One easy way to make sure you are not doing this is to use @synthesize var = _var instead of the property and ivar having the same name. That way, if you forget self.var = obj and just use var = obj , it will complain.

• I encountered an error in gestures and tabs - the gestures added by IB were not saved on the tabs - I registered it here

Failure to use gesture recognizers in StoryBoard

In these cases, Zombies should help - so it does not help, that you probably do not prematurely cause a release. Most likely, you are overloading the memory - I would check all throws and wherever you use built-in arrays or pointers without objects to make sure that you do not go beyond. Guard Malloc can help

https://developer.apple.com/library/ios/#documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

Answer 2

Well, finally, I realized - neali.

I don't know yet which part was wrong. Finally, I found out that the problem is with the UITextView. The original text view was not intended for editing. But I wanted to receive sensory events. so I turned to one of the tips: (iPhone) How to handle strokes in a UITextView? I assigned "self" (a subclass of UIViewController) as a UITextView delegate and barely executed the protocol this way:

 - (BOOL)textViewShouldBeginEditing:(UITextView *)textView{ [self userShow:nil]; //Within this method a subsequent UIViewController subclass/object is created and pushed. return FALSE; } - (BOOL)textViewShouldEndEditing:(UITextView *)textView{ return TRUE; } - (void)textViewDidBeginEditing:(UITextView *)textView{ return; } - (void)textViewDidEndEditing:(UITextView *)textView{ return; } - (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text{ return TRUE; } - (void)textViewDidChange:(UITextView *)textView{ return; } - (void)textViewDidChangeSelection:(UITextView *)textView{ return; } 

The goal was to actually avoid editing, but to get an event when the user touches the UITextView area and triggers some action. In this case, the following view controller was created and added to the navigation stack. It worked fine, but after a while, in some cases minutes (!), The application crashed. Thanks to the answer from Lou and his blog, I was able to get EXC_BAD_ACCESS much closer to calling textViewShouldBeginEditing. Like an early departure from EXC_BAD_ACCESS, I commented on a UITextView and called the view controller, which is called using another UIButton element. (Just a quick workaround) Fortunately, this did the trick. The app no ​​longer crashed. Now I will move on to a more complex implementation, which will bring the same user interface, but will call another view controller to another, but save.

I provide this answer in case anyone else comes across the same question. If you have an explanation as to which part exactly caused the problem, then your punch is much appreciated.

Answer 3

Try to start the application using the tools (Product> Profile) and select the Leaks template. This may give you clues about where the error is. More here

Answer 4

It looks like you don't have an exception checkpoint. Xcode does not create it by default. Open the “Breakpoint Navigator” (cmd + 6), click on the “+” in the lower left corner and select “Add Exception Breakpoint” in the menu that appears. Click Finish, and you should find that you are now breaking down close to where the problem is.

Without this, you often find that the debugger unloads you into main without specifying in the stack trace how you got there.