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.
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.
* See the Kerni's response below in the comments *
Related
With the release of iOS 9, we are seeing several crash reports for what appears to be a bug from Apple's side of things in iOS 9. This is happening across device types (iPhone, iPad and iPod). I am looking to find out why this may be happening and if there is anything I can do to work around it. This stack is being reported through our crash reporting system (Crashlytics) so unfortunately I don't have reproducible steps or code, but I will try and answer any questions as best as I can. The stack is as follows:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x34a27ad6 objc_msgSend + 21
1 CoreFoundation 0x230d3db9 -[__NSArrayM dealloc] + 148
2 libobjc.A.dylib 0x34a34f67 objc_object::sidetable_release(bool) + 150
3 libobjc.A.dylib 0x34a353a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 388
4 CoreFoundation 0x230cbfa9 _CFAutoreleasePoolPop + 16
5 UIKit 0x27523cd9 _prepareForCAFlush + 312
6 UIKit 0x2752886b _beforeCACommitHandler + 10
7 CoreFoundation 0x2317a509 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
8 CoreFoundation 0x2317880d __CFRunLoopDoObservers + 280
9 CoreFoundation 0x23178c3f __CFRunLoopRun + 958
10 CoreFoundation 0x230cc249 CFRunLoopRunSpecific + 520
11 CoreFoundation 0x230cc035 CFRunLoopRunInMode + 108
12 GraphicsServices 0x2c182ad1 GSEventRunModal + 160
13 UIKit 0x272e18a9 UIApplicationMain + 144
14 APPNAMEHERE 0x000ec967 main (main.m:14)
For me the problem was that I was showing and dismissing the keyboard when the application was minimized.
[self.textView becomeFirstResponder];
[self.textView resignFirstResponder];
I performed the above code on the applicationWillResignActive event.
removing this code fixed the crash.
We encountered the a crash with a similar stack trace, and after a long investigation we found out that it was related to an other crash; fixing that also fixed this, however I'm still unsure how the two crashes are related.
Here are the details about the other crash:
We had a function call in one of our methods like
AudioServicesAddSystemSoundCompletion(self.soundID,
[[NSRunLoop currentRunLoop] getCFRunLoop],
kCFRunLoopDefaultMode,
AudioServicesSystemSoundCompletion,
(void *)CFBridgingRetain(self));
where AudioServicesSystemSoundCompletion looked like
void AudioServicesSystemSoundCompletion(SystemSoundID ssID, void *clientData) {
AudioServicesRemoveSystemSoundCompletion(ssID);
CFRelease(clientData);
}
Executing that function call two or more times simultaneously caused the app to crash. We fixed this by passing NULL instead of (void *)CFBridgingRetain(self) and removing the CFRelease(clientData); line.
Since this fix we no longer see the '_prepareForCAFlush' crash anymore.
Also note that according to Crashlytics the device had very high memory usage each time the crash has reproduced.
Hope this helps!
I'm also facing this issue and I think that I found what might be causing it.
Are you guys by any chance using SDWebImage?
Because that's the only place where I found that CFRunLoopRun() is being called and also other people complained on:
Dead thread ticket -> App Crash
Seems to be only affecting devices with 32-bit processors A5 and A6 - iPod 5th Gen, iPhone 4S/5/5C, iPad 2/Mini).
No repro on our side either.
These crashes started and ramped up with iOS 9 release and adoption.
iOS v9.0.1 does not seem to fix it.
I'm running corona SDK with a chartboost plugin, and I'm experiencing crashes about 20% of the time at startup, when I try to initialize the plugin (which I can't edit, I don't have the source).
Here's the symbolicated crash report: http://pastebin.com/id1AsjmN
I've been reading up a little on how to make sense of these crash reports, and from what I understand, these two frames in the main thread:
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
Are the most critical to understanding my problem. How can I understand what these lines mean? The "object:file:lineNumber:description:" and "raise:format:arguments:" business seems almost cruel, because I feel like those should be filled in with information that would help me -- what class, and line number we're talking about. Am I right? Are these placeholders in the error message? What am I not grokking here? Is there ANY way of knowing where this error came from?
It's not symbolicated crash log. To be more precise, partially symbolicated.
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
11 UIKit 0x2d00946e -[UINib initWithNibName:directory:bundle:] + 158
12 UIKit 0x2d00955c +[UINib nibWithNibName:bundle:] + 56
13 splashboardd 0x000bee8c 0xbc000 + 11916
Somewhere in your splashboard code something is called (0x000bee8c 0xbc000 + 11916 - not symbolicated). This calls +[UINib nibWithName:bundle:], which calls -[UINib initWithNibName:directory:bundle:], which causes your crash.
Google for How to symbolicate crash log and when you'll succeed, 0xbc000 + 11916 will be replaced with class name, method name, line number, ... That's the place where the problem is. Also that's the reason why you should keep debug symbols for your app as well. To be able to symbolicate it.
Also sometimes there's useful info in console as well. Additional messages, which can help you with debugging.
If I disable notifications for the app, I don't sync and the app runs fine. If they're enabled, and the code notices and tries to sync - it falls apart.
App has been working 100% fine for weeks with no code changes. Wondering if switching between schemes of the same build on the same test device is hosing things.
Works fine run with the same, non-debug/production, scheme from Xcode to the device. But installed via Testflight app of an official archived build it crashes. Very weird.
Any insights?
Thread : Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x000000018714659c __exceptionPreprocess + 132
1 libobjc.A.dylib 0x00000001978980e4 objc_exception_throw + 60
2 CoreFoundation 0x00000001870311f8 -[__NSDictionaryM setObject:forKey:] + 972
3 0x0000000100522580 -[SBLocalStorage updateWithRegistrationName:registration:] (SBLocalStorage.m:89)
4 0x00000001005223fc -[SBLocalStorage updateWithRegistration:] (SBLocalStorage.m:59)
5 0x000000010051ceb4 __72-[SBNotificationHub retrieveAllRegistrationsWithDeviceToken:completion:]_block_invoke (SBNotificationHub.m:314)
6 0x000000010051b31c -[SBURLConnection connectionDidFinishLoading:] (SBURLConnection.m:115)
7 CFNetwork 0x0000000186beae70 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 80
8 CFNetwork 0x0000000186beae00 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 208
9 CFNetwork 0x0000000186beaf7c -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 60
10 CFNetwork 0x0000000186abf8e4 ___ZN27URLConnectionClient_Classic26_delegate_didFinishLoadingEU13block_pointerFvvE_block_invoke + 104
11 CFNetwork 0x0000000186b88540 ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 104
12 CFNetwork 0x0000000186aabb54 RunloopBlockContext::_invoke_block(void const*, void*) + 76
13 CoreFoundation 0x0000000187028aac CFArrayApplyFunction + 68
14 CFNetwork 0x0000000186aaba00 RunloopBlockContext::perform() + 136
15 CFNetwork 0x0000000186aab8b4 MultiplexerSource::perform() + 312
16 CFNetwork 0x0000000186aab6e0 MultiplexerSource::_perform(void*) + 68
17 CoreFoundation 0x00000001870fe9ec __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
18 CoreFoundation 0x00000001870fdc90 __CFRunLoopDoSources0 + 264
19 CoreFoundation 0x00000001870fbd40 __CFRunLoopRun + 712
20 CoreFoundation 0x00000001870290a4 CFRunLoopRunSpecific + 396
21 GraphicsServices 0x00000001901c35a4 GSEventRunModal + 168
22 UIKit 0x000000018b95aaa4 UIApplicationMain + 1488
23 0x00000001000dabc0 main (main.m:14)
24 libdyld.dylib 0x0000000197f06a08 start + 4
This is 1.2.4 version of the Windows Messaging Azure SDK
Edit: Also v2.0
Edit: I tracked it down to this line of code, which I believe is falling over because of a nil template name. In my server code which also interacts with the hub, I'm not passing template name so it's getting nilled out. But that alone doesn't cause the crash. There is a scenario I'm yet to uncover with the device ID changing, or similar, that is making this surface. I'll update when I figure out what.
Edit 2: For the few users who experienced this, the common characteristic of their data in Azure, and as hinted by the code above, was a missing TemplateName. It is possible to manually force the crash by passing a nil name to:
[hub registerTemplateWithDeviceToken:deviceToken
name:nil
jsonBodyTemplate:alertTemplate
expiryTemplate:#"0"
tags:[NSSet setWithArray:tags]
completion:^(NSError* error) {
I don't know what was happening with Azure such that a call with a valid string name wasn't updating the Azure data and returning a valid value, but my gut feeling is there is a race condition and bug on the Azure side.
We're now crawling through the registered user data in Azure and fixing the nil template names, which we've verified fixes the issue for users that were caught up in this cycle of sadness.
Update - this was indeed the fix. Haven't had the crash since correcting the bad user template data.
Original answer:
Not a very fulfilling solution, but I disabled notifications for the app (Via OS Settings), used the app to unsubscribe to all the tags I was subscribed to (lots). Then re-enabled notifications, and the crash no longer occurs.
Now both my production Xcode scheme and test flight install result in the same device ID. That doesn't seem to have been the root of the issue, but who knows. Would be really interesting to know what the SDK is trying to persist at the point where it crashes - that would be the surest way to figure out what happened.
My App does not crash on my iDevices, but the apple review team says it is crashing on ipad 6.0.1. This is the relevant part of the resymbolicated log:
Last Exception Backtrace:
0 CoreFoundation 0x327fb29e __exceptionPreprocess + 158
1 libobjc.A.dylib 0x394dd97a objc_exception_throw + 26
2 UIKit 0x38897d54 +[UIStoryboard storyboardWithName:bundle:] + 436
3 UIKit 0x386da406 -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 38
4 UIKit 0x38563794 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 524
5 UIKit 0x3850bc34 -[UIApplication handleEvent:withNewEvent:] + 1000
6 UIKit 0x3850b6c8 -[UIApplication sendEvent:] + 68
7 UIKit 0x3850b116 _UIApplicationHandleEvent + 6150
8 GraphicsServices 0x35c8759e _PurpleEventCallback + 586
9 CoreFoundation 0x327d067e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 10
10 CoreFoundation 0x327cfee4 __CFRunLoopDoSources0 + 208
11 CoreFoundation 0x327cecb2 __CFRunLoopRun + 642
12 CoreFoundation 0x32741eb8 0x32739000 + 36536
13 CoreFoundation 0x32741d44 CFRunLoopRunInMode + 100
14 UIKit 0x38562478 -[UIApplication _run] + 664
15 UIKit 0x3855f2f4 UIApplicationMain + 1116
16 MyApp 0x0007362e main (main.m:16)
17 MyApp 0x000735e4 start + 36
Does this mean that the Storyboard is the problem (line 2)?
To answer your question:
Does this mean that the Storyboard is the problem (line 2)?
It means that the most likely problem is related to the storyboard loading - either with the storyboard or the bundle - as that's where the exception is being thrown from. Without knowing the source code of UIStoryboard and what's on line 436 that makes it throw an exception, that's probably about as specific as you'll get from a non-Apple employee.
To get beyond that and actually reproduce the crash locally (so you can work toward fixing it):
Validate packaging / do a clean/fresh install (as suggested in the comments)
Try on a different device (perhaps there's something leftover that a clean isn't removing properly)
Try an older iOS version (maybe they're accidentally giving you incorrect information to the iOS version?)
Try simulating low memory environment while your app is in the background (maybe the crash is related to your app closing and restarting in the background in this situation?)
More likely you'll want to get more info from the review team than just a stack trace if you can't reproduce the issue:
Can you get more exact reproduction steps on how they are causing the crash?
Is this an update to an existing app? Might they have an old version of your app that hasn't been cleaned properly?
My guess is that at some point you changed the name of the storyboard file but did not reflect that change in Xcode under (project) > (target) > General > Deployment Info > Main Interface.
Consequently, it's still working on your device (because you still have the storyboard file with the old name installed on that device, as well as the new one), but it crashes when newly-installed on other devices, where only the storyboard file with the new name exists.
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/