0

I'm searching for 5 days ago about this crash, but I can find why my app crash sometimes. I'm using the Crittercism library to log my crash. The dSYM file is correctly uploaded on the Crittercism website. Here the crash log from Crittercism: 

 0 libobjc.A.dylib 0x38540626 objc_msgSend + 6
 1 UIKit 0x307baaf7 -[_UIModalItemsCoordinator _notifyDelegateModalItem:tappedButtonAtIndex:] + 95
 2 UIKit 0x307ba96d -[_UIModalItemAlertContentView tableView:didSelectRowAtIndexPath:] + 749
 3 UIKit 0x306c205f -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1079
 4 UIKit 0x30774377 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215
 5 UIKit 0x306236f5 _applyBlockToCFArrayCopiedToStack + 317
 6 UIKit 0x3059c55b _afterCACommitHandler + 431
 7 CoreFoundation 0x2dd532a5 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 21
 8 CoreFoundation 0x2dd50c49 __CFRunLoopDoObservers + 285
 9 CoreFoundation 0x2dd50f8b __CFRunLoopRun + 731
 10 CoreFoundation 0x2dcbbf0f CFRunLoopRunSpecific + 523
 11 CoreFoundation 0x2dcbbcf3 CFRunLoopRunInMode + 107
 12 GraphicsServices 0x32bc0663 GSEventRunModal + 139
 13 UIKit 0x3060716d UIApplicationMain + 1137
 14 myApp 0x000c3357 main (main.m:16)
 15 libdyld.dylib 0x38a43ab7 start + 3

The thing is: I have many UITableView in my app. But I can't find which one it is. How do I have to process to debug this crash ? I didn't find some useful information on Apple Developer Center. I try to use the atos command to symbolicate the file, but no useful information. It's exactly the same info than on the Crittercism website.

Here the command I used: atos -arch armv7 -o myApp (to enter interactif mode, then, enter each memory address like : 0x307baaf7) I have only the myApp.app.dSYM archive, and to use this command (above), I used the file the archive at path: Contents/Resources/DWARF/myApp

I'm really lost. Any idea ? Suggestions ? Thank you so much for your help.

EDIT 1:

I've checked all my UIAletView and delegate of UIAlertView: all is ok.

I see the crash log on Crittercism, (around 120 crashes for 63 users on iOS 7 only, iPhone and iPad). I can't reproduced it ! I really don't understand.

Lapinou
  • 1,467
  • 2
  • 20
  • 39
  • 1
    possible duplicate of [iOS 7 bug or my bug in UIAlertView](http://stackoverflow.com/questions/19001528/ios-7-bug-or-my-bug-in-uialertview) – Kerni Jun 20 '14 at 08:06
  • Maybe yes. In fact, I have an UIAlertView with delegate = self, and no delegate method implemented. I will check if this crash persist or not and stay tune to you. – Lapinou Jun 20 '14 at 12:41
  • Well. It's me again. After set delegate = nil because I don't use any delegate methods, the crash is still there. I can't reproduce it but I see in crittercism that some users have this crash, and I don't know where is it in my code. It's really painful, I don't understand. – Lapinou Aug 13 '14 at 08:57

2 Answers2

1

Frame 14 already shows the correct symbol, which is main.m line 16. Using atos with the address as written in the stackframe like you did is wrong, see this stackoverflow explanation. As such it is not possible for a crash report to tell you which table view is causing such a memory issue.

Based upon the above you may not be able to get the exact table view from the stack trace itself, but with Crittercism there are additional features (such as Breadcrumbs) that allow for capturing a trail beyond just the stack.

My recommendation is to add a breadcrumb in the viewDidLoad of the TableViewController and grab/define the name of the table view there. That way you can step through the breadcrumbs and know that leading up to the crash you were in this tableview.

That should help you for better capturing this scenario in the future.

As for this particular stack trace. You can potentially use the techniques described in this post to help you better understand the true origins of the objc_msgSend.

Community
  • 1
  • 1
pixelknitter
  • 869
  • 6
  • 15
0

* See the Kerni's response below in the comments *

Lapinou
  • 1,467
  • 2
  • 20
  • 39
  • 1
    Nope, this is wrong! Frame 14 already shows the correct symbol, which is `main.m line 16`. Using atos with the address as written in the stackframe like you did is wrong, see http://stackoverflow.com/questions/13574933/ios-crash-reports-atos-not-working-as-expected/13576028#13576028 It is **not** possible for a crash report to tell you which table view is causing such a memory issue. – Kerni Jun 20 '14 at 08:00
  • Thank you for your explanation Kerni! I edited my (bad) answer ;) – Lapinou Jun 20 '14 at 12:04