I am using IBM Mobile First V 7.1 on an iOS app, the problem is after my app is submitted to the store, Fabric starts to send me weird exception:
Fatal Exception: Unable to generate key pair. Keychain returned the
following status: -25308
and every time I check Crashlytics I see a different trace stack of the exception, and the below is one of the exception that I got:
Fatal Exception: Unable to generate key pair.
0 CoreFoundation 0x18db1d1b8 __exceptionPreprocess
1 libobjc.A.dylib 0x18c55455c objc_exception_throw
2 CoreFoundation 0x18db1d100 -[NSException initWithCoder:]
3 RTA 0x1012ba4a0 +[WLCertManager generateKeyPair:withPublicKeyLabel:withKeySize:]
4 RTA 0x1012be730 +[WLCertManager signJWSPartsWithPayload:withPrivateKeyLabel:withPublicKeyLabel:withKeySize:]
5 RTA 0x10129ffcc -[WLAuthorizationManager buildJWSPartsWithClientId:]
6 RTA 0x10128607c __71-[WLRequest addClientInstanceIdHeaderWithRequest:withCompetionHandler:]_block_invoke
7 RTA 0x10129b4ec -[WLAuthorizationManager clientInstanceIdWithCompletionHandler:]
8 RTA 0x101285f2c -[WLRequest addClientInstanceIdHeaderWithRequest:withCompetionHandler:]
9 RTA 0x101284f40 -[WLRequest sendRequest:path:withOptions:]
10 RTA 0x10128685c -[WLRequest makeRequest:withOptions:withCallback:]
11 RTA 0x1012862f4 -[WLRequest makeRequest:withOptions:]
12 RTA 0x1012c36e8 -[WLClient invokeProcedure:withDelegate:options:]
13 RTA 0x1002e8d60 specialized FavouritesModel.getFavouritesList(FavouritesRequestDelegate?) -> () (FavouritesModel.swift)
14 RTA 0x1002e8484 FavouritesModel.getFavouritesList(FavouritesRequestDelegate?) -> () (FavouritesModel.swift:21)
15 RTA 0x10037508c MainDashboardViewController.pullToRefreshAction() -> () (MainDashboardViewController.swift:1793)
16 RTA 0x100389dc8 partial apply for MainDashboardViewController.(upperViewAnimation() -> ()).(closure #2).(closure #4) (MainDashboardViewController.swift:614)
17 Foundation 0x18e61a46c __NSFireDelayedPerform
18 CoreFoundation 0x18dacb1d8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
19 CoreFoundation 0x18dacaeec __CFRunLoopDoTimer
20 CoreFoundation 0x18daca7a8 __CFRunLoopDoTimers
21 CoreFoundation 0x18dac83a4 __CFRunLoopRun
22 CoreFoundation 0x18d9f62b8 CFRunLoopRunSpecific
23 GraphicsServices 0x18f4aa198 GSEventRunModal
24 UIKit 0x193a3d7fc -[UIApplication _run]
25 UIKit 0x193a38534 UIApplicationMain
26 RTA 0x100913fe0 main (AppDelegate.swift:35)
27 libdispatch.dylib 0x18c9d95b8 (Missing)
After some investigation and searching I found some recommendation to enable Keychain Sharing and the below screenshot is my app entitlement:
Please any advise how I can solve this problem or is there any missing configuration should be applied
Fatal Exception: Unable to generate key pair. Keychain returned the
following status: -25308
The above error occurs when app tries to generate key pair while phone is locked or while app is running during background mode. It seems to be your app is doing MFP requests while app is background or phone is locked.
Currently Mobilefirst iOS 7.x Client SDK's do not support MFP requests running in the background. You can use non-MFP API's if you are accessing unsecured resources.
Related
I have an older Objective-C application that I upgraded recently in order to add new functionalities. I'm using now AFNetworking version 4.0. All is working now even in the newest version of iOS except on iOS 10. When I run it on the simulator, the application crash immediately in the splashSreen. From the logs I know that it's in relation with NSURLSession but can't figure out how to solve it. I've found similar issues but there solutions are not up-to-date.
This is what I have in the thread stack when the crash happened
And this is the crash description from the console log with some previous Firebase calls:
2020-11-19 18:48:11.257 myApp[63563:2715840] Appdelegate, applicationDidBecomeActive
Nov 19 18:48:11 myApp[63563] <Warning>: 6.34.0 - [Firebase/Analytics][I-ACS800023] No pending snapshot to activate. SDK name: app_measurement
Nov 19 18:48:11 myApp[63563] <Notice>: 6.34.0 - [Firebase/Analytics][I-ACS023012] Analytics collection enabled
Nov 19 18:48:11 myApp[63563] <Notice>: 6.34.0 - [Firebase/Analytics][I-ACS023220] Analytics screen reporting is enabled. Call +[FIRAnalytics logEventWithName:FIREventScreenView parameters:] to log a screen view event. To disable automatic screen reporting, set the flag FirebaseAutomaticScreenReportingEnabled to NO (boolean) in the Info.plist
2020-11-19 18:48:11.645 myApp[63563:2715921] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7fa48d318df0 of class __NSCFLocalDataTask was deallocated while key value observers were still registered with it. Current observation info: <NSKeyValueObservationInfo 0x600000031ce0> ( <NSKeyValueObservance 0x60000024a200: Observer: 0x6080000f5980, Key path: state, Options: <New: NO, Old: NO, Prior: NO> Context: 0x0, Property: 0x608000253ad0> )'
*** First throw call stack: (
1 libobjc.A.dylib 0x0000000112558141 objc_exception_throw + 48
2 CoreFoundation 0x0000000112b5c625 +[NSException raise:format:] + 197
3 Foundation 0x000000010fb52b53 NSKVODeallocate + 294
4 libobjc.A.dylib 0x000000011256cb8e _ZN11objc_object17sidetable_releaseEb + 202
5 libsystem_blocks.dylib 0x0000000113ff799d _Block_release + 111
6 libdispatch.dylib 0x0000000113f6405c _dispatch_client_callout + 8
7 libdispatch.dylib 0x0000000113f40c6e _dispatch_continuation_pop + 1020
8 libdispatch.dylib 0x0000000113f4e5db _dispatch_source_invoke + 1401
9 libdispatch.dylib 0x0000000113f42c47 _dispatch_queue_serial_drain + 981
10 libdispatch.dylib 0x0000000113f43669 _dispatch_queue_invoke + 1084
11 libdispatch.dylib 0x0000000113f45ec4 _dispatch_root_queue_drain + 634
12 libdispatch.dylib 0x0000000113f45bef _dispatch_worker_thread3 + 123
13 libsystem_pthread.dylib 0x000000011430d6d5 _pthread_wqthread + 220
14 libsystem_pthread.dylib 0x000000011430d57b start_wqthread + 15 ) libc++abi.dylib: terminating with uncaught exception of type NSException
We are using authentication by email link in our Flutter app with firebase_auth package, and we are seeing crashes on iOS devices with
Fatal Exception: NSInvalidArgumentException
The link provided is not valid for email/link sign-in. Please check the link by calling isSignInWithEmailLink:link: on Auth before attempting to use it for email/link sign-in.
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x18f2095f0 __exceptionPreprocess
1 libobjc.A.dylib 0x18ef2bbcc objc_exception_throw
2 CoreFoundation 0x18f0ffb28 -[NSCache init]
3 Runner 0x102fde5ec +[FIRAuthExceptionUtils raiseInvalidParameterExceptionWithReason:] + 30 (FIRAuthExceptionUtils.m:30)
4 Runner 0x102fcf970 -[FIRAuth internalSignInAndRetrieveDataWithEmail:link:callback:] + 729 (FIRAuth.m:729)
5 Runner 0x102fd0028 -[FIRAuth internalSignInAndRetrieveDataWithCredential:isReauthentication:callback:] + 770 (FIRAuth.m:770)
6 Runner 0x102fcef5c __43-[FIRAuth signInWithEmail:link:completion:]_block_invoke + 562 (FIRAuth.m:562)
7 libdispatch.dylib 0x18eece9a8 _dispatch_call_block_and_release
8 libdispatch.dylib 0x18eecf524 _dispatch_client_callout
9 libdispatch.dylib 0x18eeacb3c _dispatch_lane_serial_drain$VARIANT$armv81
10 libdispatch.dylib 0x18eead54c _dispatch_lane_invoke$VARIANT$armv81
11 libdispatch.dylib 0x18eeb684c _dispatch_workloop_worker_thread
12 libsystem_pthread.dylib 0x18ef20b74 _pthread_wqthread
13 libsystem_pthread.dylib 0x18ef23740 start_wqthread
We added some logging for investigation and saw that invalid link was
com.xxxx.xxxx://google/link/?request_ip_version=IP%5FV6&match_message=No%20pre%2Dinstall%20link%20matched%20for%20this%20device%2E
It seems that it doesn't affect 100% of users who are trying to log in with an email link and we were not able to reproduce it on our devices even once. What could produce a link like that?There doesn't seem to be any documentation that would mention this error message
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!
We have tried to run WL 6.1 Fix Pack FP02 app on iOS 9 and got the following error in main.m file:
‘Application windows are expected to have a root view controller at the end of application launch’
The exception is thrown on this line of main.m:
int retVal = UIApplicationMain(argc, argv, appClass, #”MyAppDelegate”);
Any help would be greatly appreciated.
Below is the stack trace from xcode 7 :
Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Application windows are expected to have a root view controller at the end of application launch'
*** First throw call stack:
(
0 CoreFoundation 0x047e0a94 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x0429fe02 objc_exception_throw + 50
2 CoreFoundation 0x047e092a +[NSException raise:format:arguments:] + 138
3 Foundation 0x00f0e3e6 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 118
4 UIKit 0x012b3568 -[UIApplication _runWithMainScene:transitionContext:completion:] + 3674
5 UIKit 0x012d6905 __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke3171 + 68
6 UIKit 0x012afbae -[UIApplication workspaceDidEndTransaction:] + 163
7 FrontBoardServices 0x07c1cccc __37-[FBSWorkspace clientEndTransaction:]_block_invoke_2 + 71
8 FrontBoardServices 0x07c1c7a3 __40-[FBSWorkspace _performDelegateCallOut:]_block_invoke + 54
9 FrontBoardServices 0x07c3a1cb -[FBSSerialQueue _performNext] + 184
10 FrontBoardServices 0x07c3a602 -[FBSSerialQueue _performNextFromRunLoopSource] + 52
11 FrontBoardServices 0x07c398fe FBSSerialQueueRunLoopSourceHandler + 33
12 CoreFoundation 0x046fae7f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
13 CoreFoundation 0x046f0b0b __CFRunLoopDoSources0 + 523
14 CoreFoundation 0x046eff28 __CFRunLoopRun + 1032
15 CoreFoundation 0x046ef866 CFRunLoopRunSpecific + 470
16 CoreFoundation 0x046ef67b CFRunLoopRunInMode + 123
17 UIKit 0x012af497 -[UIApplication _run] + 540
18 UIKit 0x012b4cc1 UIApplicationMain + 160
19 MYAPP 0x00100f5d main + 157
20 libdyld.dylib 0x04c8ba21 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Update:
Tested with the provided Hello World project - failing
Tested with the latest available iFix - working
Please upgrade.
Without proper example that can be debugged it is difficult to answer, but it should be noted that for applications compiled with Xcode 7 to correctly function you need to make sure, at minimum, to make the following tweaks:
Disable Bitcode, as it is currently not supported.
Correctly define ATS (either allow all addresses, or correctly setup the client application with HTTPS, and the server with TLS 1.2 support).
Read more about ATS and Bitcode, here: https://developer.ibm.com/mobilefirstplatform/2015/09/09/ats-and-bitcode-in-ios9/
See if that resolves this issue. If not, you must provide an application with reproduction steps.
You should also note that 6.1 Fix Pack 2 is extremely old and you should, as an IBM customer, login to IBM Fix Central and download the latest available iFix (for Studio and Server) and upgrade. This latest iFix also contains iOS 9 related fixes, so it is advised to test with it first, in addition to the above required changes for applications compiled in Xcode 7.
From the provided example project, you are not even using Fix Pack 2, but 1. Even older...
Application windows are expected to have a root view controller at the end of application launch’
This error is caused when there is no view controller for the app to go to after the launch. This could be because you have not created one yet because you started with an empty application, you deleted the view controller, or it might be you deleted the entrance point to the main view controller.