Finally I finish my application so it is time to make some beta test. So I upload my application to itunes connect to test it out with test flight, but it keep crashing when I perform few task.
When I try to open the app from downloaded menu in test flight app.
When I try make a http request with AFnetworking
When I insert new record to CoreData
Sometime when i open the app from test flight it did not crash but show me a black screen after lauch screen.
I have been searching for 5 day without any clue. I been test it out with both release and debug mode running from xcode it doesn't crash at all. The problem only occur on if the app install from testflight. I think might be some memory allocated issues. It is a bug from testflight? How can I make the same behaviour happening at test flight happen in my xcode as well to know and fix the error.
I'm targeting ios 8.0 ++
Testing on iphone 7 plus(ios 10.2) and iphone 5s(ios 9.3).
Xcode 8.3.2
I get alot of difference crash report but most of it similiar to this one. Maybe I insert some nil value into dictionary? But why does it not happen when I build it from xcode.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x18319ee38 __exceptionPreprocess + 124
1 libobjc.A.dylib 0x182803f80 objc_exception_throw + 56
2 CoreFoundation 0x183084554 -[__NSDictionaryM setObject:forKey:] + 924
3 Cellecter 0x1001db19c 0x100040000 + 1683868
4 Cellecter 0x1001dafe4 0x100040000 + 1683428
5 CoreFoundation 0x183140eac __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
6 CoreFoundation 0x1831406cc _CFXRegistrationPost + 396
7 CoreFoundation 0x18314044c ___CFXNotificationPost_block_invoke + 60
8 CoreFoundation 0x1831a9494 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1532
9 CoreFoundation 0x18307e788 _CFXNotificationPost + 368
10 Foundation 0x183adfd1c postQueueNotifications + 684
11 CoreFoundation 0x1831547b0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
12 CoreFoundation 0x183152554 __CFRunLoopDoObservers + 372
13 CoreFoundation 0x183152884 __CFRunLoopRun + 672
14 CoreFoundation 0x18307cd10 CFRunLoopRunSpecific + 384
15 GraphicsServices 0x184964088 GSEventRunModal + 180
16 UIKit 0x188351f70 UIApplicationMain + 204
17 Cellecter 0x1001e8834 0x100040000 + 1738804
18 libdyld.dylib 0x182c1a8b8 start + 4
Updated: some how the my first and fourth question have been fix Now my question narrow it down to crashing when try to insert record into afnetworking.
This could be a lot of things.
It can be a migration issue with CoreData, a ManagedObjectContext issue.
The blackscreen could be a view issue.
Your question is too broad, we don't have code, we don't know your recent development.
Are you using real devices ? Emulators ? Which version of Xcode ? iOS deployment target ?
Please refer to this post next time you ask a question.
How to Ask
I finally manage to fix the issues. Actually the issues is quite simple, I will not be able to fix the issues if I don't symbolicate my crash report, actually the issues is on FCM, From here specifically say I need a production push certificate in order to receive the device token. Which the device token return nil every time and I attempt save the token to core data.
Related
I'm working on an iOS app that uses Realm which is installed/managed via Cocoapods. My app crashes sporadically and I'm having difficulty troubleshooting the problem because my stack trace doesn't show me the method names related to Realm. I am deploying a debug build of my app to the phone via Xcode and I have the Debug Information Format option set to DWARF with dSYM File. In the stack trace below you can see that my code appears to be symbolicated but the method names in Realm are just addresses and offsets. Unfortunately, I'm somewhat new to troubleshooting with Xcode but I'm under the assumption that this means the Realm debug symbols could not be found? If anyone can explain to me how to correct this, I'd really appreciate it!
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x18316ad8c __exceptionPreprocess + 228
1 libobjc.A.dylib 0x1823245ec objc_exception_throw + 55
2 Realm 0x10814e238 0x108030000 + 1172024
3 Realm 0x10814ffa0 0x108030000 + 1179552
4 Realm 0x10814ff74 0x108030000 + 1179508
5 MyAppName 0x104af31a4 closure #1 in closure #2 in processOutgoingMessage(outgoingMessage:) + 4452772 (ProcessOutgoingMessage.swift:51)
6 MyAppName 0x1046cd168 _T0Ieg_IeyB_TR + 102760 (DataSource.swift:0)
7 libdispatch.dylib 0x182a5caa0 _dispatch_call_block_and_release + 23
8 libdispatch.dylib 0x182a5ca60 _dispatch_client_callout + 15
9 libdispatch.dylib 0x182a9dd80 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 963
10 CoreFoundation 0x183113070 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 11
11 CoreFoundation 0x183110bc8 __CFRunLoopRun + 2271
12 CoreFoundation 0x183030da8 CFRunLoopRunSpecific + 551
13 GraphicsServices 0x185015020 GSEventRunModal + 99
14 UIKit 0x18d04d758 UIApplicationMain + 235
15 MyAppName 0x104a7919c main + 3953052 (AppDelegate.swift:18)
16 libdyld.dylib 0x182ac1fc0 start + 3
UPDATE - as it turns out, the Build Settings for the Pods project (recall that I'm using Realm via Cocoapods) needed to also have the Debug Information Format set to DWARF with dSYM File for debug builds. My app hasn't crashed again yet but I did notice that when I cleaned and rebuilt the app this time it appeared to be including the debug symbols for Realm so here's hoping.
We've had a few very bizarre crashes in our app recently. They are not reliably reproducable. The crashes have all occurred on iOS 11 devices so far. Our app is written in Swift 3.2. We are using Xcode 9.0.1 with the standard build system (not the new Swift build system). It seems that after performing a certain web request, the app crashes with the below stack trace:
Crashed: com.apple.main-thread
0 OurFramework 0x105283e84 __swift_deallocate_boxed_opaque_existential_0 + 2588
1 OurFramework 0x10528366c __swift_deallocate_boxed_opaque_existential_0 + 516
2 OurFramework 0x10528b368 swift_rt_swift_storeEnumTagSinglePayload + 24748
3 OurFramework 0x1052911cc swift_rt_swift_storeEnumTagSinglePayload + 48912
4 OurFramework 0x1052133d8 __swift_memmove_array32_8 + 1336
5 OurFramework 0x10521304c __swift_memmove_array32_8 + 428
6 OurFramework 0x105292504 swift_rt_swift_storeEnumTagSinglePayload + 53832
7 Alamofire 0x1057cac64 _T09Alamofire11DataRequestC8responseACXDSo13DispatchQueueCSg5queue_x0D10SerializeryAA0B8ResponseVy16SerializedObjectQzGc17completionHandlertAA0biH8ProtocolRzlFyycfU_yycfU_AA0biH0VyypG_Tg5 + 264
8 Alamofire 0x1057ca3f8 _T0Ix_IyB_TR + 36
9 libdispatch.dylib 0x1860c5088 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1860c5048 _dispatch_client_callout + 16
11 libdispatch.dylib 0x1860d1b74 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1016
12 CoreFoundation 0x1866e9eb0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation 0x1866e7a8c __CFRunLoopRun + 2012
14 CoreFoundation 0x186607fb8 CFRunLoopRunSpecific + 436
15 GraphicsServices 0x18849ff84 GSEventRunModal + 100
16 UIKit 0x18fbdc2e8 UIApplicationMain + 208
17 OurApp 0x104de98b0 main (main.swift:19)
18 libdyld.dylib 0x18612a56c start + 4
We are using Crashlytics to track our crashes and I'm not sure if it's because of a symbolication issue that I don't see more info than this but the trace indicates that something is going awry during a web request. Our app uses Alamofire to make web requests. Results from our testing where this crash occurred also support this theory since the crashes always occurred right after the app made a request to our backend. Could it be that in iOS 11 something changed in the underlying NSURLSession that Alamofire uses? Maybe iOS 11 is using a different caching strategy or something that's causing alamofire to invoke our result completion handler in a way that causes this crash? Has anyone seen this kind of crash before? What do __swift_deallocate_boxed_opaque_existential and swift_rt_swift_storeEnumTagSinglePayload mean? Any help is greatly appreciated, thank you!
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.
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.