0

I'm guessing that this problem is a lifecycle problem. The app receives a memory warning and tries to unload some user interface items. But I'm not 100% sure how to interpret the error in the context of the last reported item on the stack trace.

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xa0d9f968
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                     0x361dc026 objc_msgSend_stret + 18
1   TheApp                              0x000b4d31 -**[TheAppFeedController removeAdView]** (TheAppFeedController.m:**189**)
2   TheApp                              0x0000d68d -[TheAppViewController viewDidUnload] (TheAppViewController.m:177)
3   TheApp                              0x000b4a63 -[TheAppFeedController viewDidUnload] (TheAppFeedController.m:137)
4   UIKit                               0x32e66a37 -[UIViewController unloadViewForced:] + 251
5   UIKit                               0x32fae3ad -[UIViewController purgeMemoryForReason:] + 65

So the stack trace points to this method which doesn't really make sense why it would throw this error.

-(void) removeAdView {
    [super removeAdView];
    [self fixLayoutForAdRemoval:self.tableView];
}

The one thing I did notice when you look up the stack is that [super viewDidUnload] was being called as the first line of code. So I moved it to the bottom, after I do all my "unloading" work. There seems to be some disagreement online whether this really matters or not, some SO answers say that the super class' viewDidUnload method does nothing, and as such it doesn't matter if you call it at the beginning or the end.

So I've made that change, but since I've never been able to reproduce this error I'm not sure if it's the actual fix. Wanted to get more opinions on the problem to see if my reasoning is correct.

Community
  • 1
  • 1
Joel Martinez
  • 46,929
  • 26
  • 130
  • 185
  • I am not sure I understood: by moving `[super viewDidUnload]`, the crash was fixed; If you reinstate it as the first line, the crash happens; is this what you are saying? – sergio Oct 24 '12 at 15:48
  • I mentioned that I've never been able to reproduce this error. I'm receiving this crash log through HockeyApp from "the wild" ... so I am looking to resolve this for our customers – Joel Martinez Oct 24 '12 at 16:05
  • Which line is `TheAppFeedController.m line 189`? – Joachim Isaksson Oct 24 '12 at 16:47
  • That's the strange part, 189 is the closing bracket of the `removeAdView` method :-/ – Joel Martinez Oct 24 '12 at 17:16

1 Answers1

1
[super removeAdView];
[self fixLayoutForAdRemoval:self.tableView];

If removeAdView is tearing down parts of self; if it is causing self to be released to the point of deallocation, then the subsequent call to fixLayoutForAdRemoval: could easily fail.

Turn on Zombie detection in Instruments and see what it detects.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • I was under the impression that viewDidUnload would not be called after dealloc. Also, zombies hasn't revealed anything ... remember I've not been able to reproduce this locally; it's only been detected through crash log reporting (hockeyapp) in production. – Joel Martinez Oct 24 '12 at 17:19
  • Ahh -- Ok. Hrm... with optimization on, the compiler sometimes loses track of line numbers, hence the line number being off isn't unheard of. If the crash log includes a list of dynamic libraries in play, check to see if it is on a jailbroken device. – bbum Oct 24 '12 at 17:34
  • Is there a specific library I should be looking for to determine if it's running on a jailbroken device? – Joel Martinez Oct 24 '12 at 17:44
  • Typically, you'll see something like Cydia or libBac0n in the dylib list. Or libraries in odd places. – bbum Oct 24 '12 at 19:55