6

I am running out of ideas. I receive an EXC_BAD_ACCESS on a project using ARC. According to the debugger it is within main(). NSZombieEnabled is set to YES but I do not see any callstack or Class/Type or anything. The same for the Inspector/Profile. All I get is "session timed out" some time after the app crashed.

And it is hard to locate within my code.

I am setting traces like

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

all over my code on enty and exit of methods, but I did not yet identify any useful pattern. All I can see is that all my methods in question have been left already when the EXC_BAD_ACCESS is thrown.

Any idea on how to isolate the issue?

Tim suggested to use back trace (bt) in gdb. The result is: 

#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
Hermann Klecker
  • 14,039
  • 5
  • 48
  • 71

4 Answers4

13

There are still ways to get EXC_BAD_ACCESS with ARC. Some that I ran into

  1. If you are doing something where you make an object and it asynchronously calls you back -- you have to make sure to keep a reference to it somewhere or ARC will release it. An example is the UIImagePicker -- you can't just make a local image picker variable and call it (and then release it when it calls you back) -- you have to make a property and hold onto it

  2. If you don't always use properties to hold onto it, you might run into trouble -- ARC is using the presence of strong and weak to know what to do -- if you use an ivar instead, you might fool ARC (not 100% sure of this). One easy way to make sure you don't do this is to use @synthesize var = _var instead of letting the property and ivar have the same name. This way, if you forget self.var = obj and just use var = obj it will complain.

  3. I ran into a bug in gestures and tabs -- the tab views didn't retain the gestures added by IB -- I documented it here

Crash when using gesture recognizers in StoryBoard

In these cases Zombies should help -- so it not helping means that you are probably not prematurely causing a release to happen. More likely you are munging memory -- I would check all casts and anywhere you are using built-in arrays or non-object pointers to make sure you aren't going out of bounds. Guard Malloc can help

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

Community
  • 1
  • 1
Lou Franco
  • 87,846
  • 14
  • 132
  • 192
  • Thanks Lou. For 1. I am doing that with the async http requests. However, I am quite sure that I cancel all open connections within the debug method of the requesting objects. However I'll double check. For 2.: Thanks. I will doulbe check whether I was using self.var in all relevant cases. 3. should not apply to my App at all. However, can you be a bit more specific on "guard malloc". This is either news to me or I did not really understand what you meant. (English is not my native language). Thank you so far. – Hermann Klecker Feb 08 '12 at 22:06
  • Follow the link for Guard Malloc help. It makes the heap more sensitive to problems. – Lou Franco Feb 09 '12 at 13:31
  • This was not directly helpfu. However, following the advice narrowed the timely window down significantly. It is much easier to find some root cause if you have an idea, at least, what to look at or for. You are running a great blog. :) – Hermann Klecker Feb 09 '12 at 19:45
  • Glad that it helped. What did the problem end up being? – Lou Franco Feb 09 '12 at 21:56
  • For details see the answer, that I provided too. Frankly, I did not trace it down to its root cause. On my view controller I had a UITextView with editable=YES but its textViewShouldBeginEditing always returned NO/FALSE. I did not want the user to edit it but I was looking for a way to catch touches on that text view. As a reaction I pushed some other view controller (which worked fine when pushed by other view controllers). Something there cause the problem and I will never really find out but simply go for some smarter implementation that provides the same user experience. – Hermann Klecker Feb 10 '12 at 11:06
  • 1
    Ah thank you for #1! That was exactly what was causing it for me. – devios1 Jul 04 '14 at 00:39
1

All right, finally I got it - nealy.

I do not yet know which detail was wrong. Finally I found out that the issue was related to an UITextView. Originally the text view was not intended to be editable. But I wanted to receive touch-events. so I follwed one of the advises given hiere: (iPhone) How to handle touches on a UITextView? I assigned 'self' (a UIViewController subclass) as the UITextView's delegate and barely implemeted the protocol in 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 intention was to actually avoid editing but receive the event when a user touches the area of the UITextView and invoke some action. In this case some subsequent view controller was created and pushed to the navigation stack. It worked fine but some time later, in some cases minutes (!) the app crashed. Thanks to Lou's answer and his blog I was able to get the EXC_BAD_ACCESS much closer to the call of textViewShouldBeginEditing. Similar to earler desparate attemts of getting around the EXC_BAD_ACCESS I commented out the UITextView and invoked the view controller to be called using some other UIButton item. (Just a quick temp workaround) Luckyly this did the trick. The app did not crash anymore. Now I will go for some more sophisticated implementation that will bring the same user experience but call the other view controller in a different but save way.

I provide this answer just in case somebody else runs into the same issue. If you have an explanation at hand about which detail exactly caused the issue, then your hit is highly appreciated.

Community
  • 1
  • 1
Hermann Klecker
  • 14,039
  • 5
  • 48
  • 71
0

Try to run you app with instruments (Product > Profile) and choose the Leaks template. It might give you hints on where the error is. More information here

Community
  • 1
  • 1
Audun Kjelstrup
  • 1,430
  • 8
  • 13
0

Sounds like you don't have an exception breakpoint set. Xcode doesn't create one by default. Open up the Breakpoints Navigator (cmd+6), click the + on the bottom left and choose "Add Exception Breakpoint" from the menu that pops up. Click "Done" and you should find that you now break close to where the problem lies.

Without this, you'll often find that the debugger dumps you in main with no hint in the stack trace as to how you got there.

Tim
  • 5,024
  • 2
  • 30
  • 58