I have a swift app with below SKProduct code
func validateProductIdentifiers() {
let identifiers:NSSet = NSSet(array: kProductIdentifiers)
let productRequest = SKProductsRequest(productIdentifiers: identifiers)
productRequest.delegate = self
productRequest.start()
}
func productsRequest(request: SKProductsRequest!, didReceiveResponse response: SKProductsResponse!) {
let product:SKProduct = response.products[0] as SKProduct
homeView!.stopActivityAnimating()
loadBulletBuy()
bulletBuy!.loadBuyData(response)
}
I have been testing this app is my device for close to a month and the app never failed/crashed during a call to this method.
Now my app is live and I found my app is crashing in above method. Crash log from my device
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 FrontLine 0x000000010016654c #objc FrontLine.GameViewController.productsRequest (FrontLine.GameViewController)(ObjectiveC.SKProductsRequest!, didReceiveResponse : ObjectiveC.SKProductsResponse!) -> () (GameViewController.swift:0)
1 StoreKit 0x0000000186638dac __34-[SKProductsRequest _handleReply:]_block_invoke + 540
2 libdispatch.dylib 0x0000000192cb53a8 _dispatch_call_block_and_release + 20
3 libdispatch.dylib 0x0000000192cb5368 _dispatch_client_callout + 12
4 libdispatch.dylib 0x0000000192cb997c _dispatch_main_queue_callback_4CF + 928
5 CoreFoundation 0x0000000181eddfa0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
6 CoreFoundation 0x0000000181edc048 __CFRunLoopRun + 1488
7 CoreFoundation 0x0000000181e090a0 CFRunLoopRunSpecific + 392
8 GraphicsServices 0x000000018afa35a0 GSEventRunModal + 164
9 UIKit 0x000000018673aaa0 UIApplicationMain + 1484
10 FrontLine 0x0000000100189640 main (AppDelegate.swift:0)
11 libdyld.dylib 0x0000000192cdea04 start + 0
I did some searching and found that it may be due to deallocation of delegate and in my case a VC. I am trying out a new solution now.
But I am not able to understand why the app never crashed in my test runs and crashing in production alone.
I tried to install my dev version of app and the app runs smooth where as if I install the app store version it crashes.
Any insight on how I can prevent such failures would be helpful
Thanks
The issue disappeared after like 3 hours in production.Looks like some payment process lags behind actual app release.
Related
I am working on my Apple Watch app. Most of my components use JSON and use the Swift Codable protocol to decode JSON.
Now I wanted to prepare my release, but I received a message by a Beta tester that the App was always crashing on his Series 3.
After I installed the TestFlight build on my Series 3 I could reproduce the issue.
The crash logs from TestFlight and the crash logs extracted from my iPhone indicate that the crash is happening while the JSON gets decoded.
I have rather complex JSON structures, but I did not do any changes to them since the last update. Furthermore, decoding JSON works fine on Xcode builds (also on Series 3) and on newer Apple Watches (Series 4 + 5). I am struggling to find out what could cause the issue.
I discovered a post in the Apple developer forums with a similar issue, but without a solution to it: https://forums.developer.apple.com/thread/124627
Here's a part of the Stacktrace of my crash log:
Date/Time: 2020-02-05 08:37:42.9924 +0100
Launch Time: 2020-02-05 08:37:40.0000 +0100
OS Version: Watch OS 6.1.2 (17S5792a)
Release Type: User
Baseband Version: 4.40.02
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x4d9aefc8 __pthread_kill + 8
1 libsystem_pthread.dylib 0x4da260be pthread_kill + 108
2 libsystem_c.dylib 0x4d9383a4 abort + 84
3 libswiftCore.dylib 0x6cffbade swift_vasprintf+ 2341598 (char**, char const*, char*) + 0
4 libswiftCore.dylib 0x6d00932c swift::TargetMetadata<swift::InProcess>::getGenericArgs+ 2396972 () const + 0
5 libswiftCore.dylib 0x6d00508c _swift_initClassMetadataImpl+ 2379916 (swift::TargetClassMetadata<swift::InProcess>*, swift::ClassLayoutFlags, unsigned long, swift::TypeLayout const* const*, unsigned long*, bool) + 28
6 libswiftCore.dylib 0x6d005c86 swift_initClassMetadata2 + 22
7 libswiftCore.dylib 0x6cfdc6fc type metadata completion function for _KeyedDecodingContainerBox + 50
8 libswiftCore.dylib 0x6d00a6c2 swift::MetadataCacheEntryBase<(anonymous namespace)::GenericCacheEntry, void const*>::doInitialization+ 2401986 (swift::ConcurrencyControl&, swift::MetadataCompletionQueueEntry*, swift::MetadataRequest) + 178
9 libswiftCore.dylib 0x6d003a0c swift_getGenericMetadata + 1124
10 libswiftCore.dylib 0x6cdf4210 KeyedDecodingContainer.init<A>+ 213520 (_:) + 40
11 libswiftFoundation.dylib 0x6d156e0a __JSONDecoder.container<A>+ 323082 (keyedBy:) + 678
12 libswiftFoundation.dylib 0x6d1a3a1c protocol witness for Decoder.container<A>+ 637468 (keyedBy:) in conformance __JSONDecoder + 18
13 libswiftFoundation.dylib 0x6d1592b6 protocol witness for Decoder.container<A>+ 332470 (keyedBy:) in conformance __JSONDecoder + 32
14 libswiftCore.dylib 0x6cfdb1cc dispatch thunk of Decoder.container<A>+ 2208204 (keyedBy:) + 24
15 WatchSonos WatchKit Extension 0x00440bf2 0x358000 + 953330
16 WatchSonos WatchKit Extension 0x0043d08c 0x358000 + 938124
17 libswiftCore.dylib 0x6cfdb156 dispatch thunk of Decodable.init+ 2208086 (from:) + 12
18 libswiftFoundation.dylib 0x6d16fbee __JSONDecoder.unbox_+ 424942 (_:as:) + 4014
19 libswiftFoundation.dylib 0x6d156816 JSONDecoder.decode<A>+ 321558 (_:from:) + 642
20 libswiftFoundation.dylib 0x6d22af98 dispatch thunk of JSONDecoder.decode<A>+ 1191832 (_:from:) + 28
21 WatchSonos WatchKit Extension 0x0045db0c 0x358000 + 1071884
22 WatchSonos WatchKit Extension 0x00461cce 0x358000 + 1088718
23 WatchSonos WatchKit Extension 0x00461bde 0x358000 + 1088478
24 WatchSonos WatchKit Extension 0x00420ffa 0x358000 + 823290
25 WatchSonos WatchKit Extension 0x00425914 0x358000 + 842004
26 libdispatch.dylib 0x4d851846 _dispatch_call_block_and_release + 10
27 libdispatch.dylib 0x4d8528b8 _dispatch_client_callout + 6
28 libdispatch.dylib 0x4d85c6b0 _dispatch_main_queue_callback_4CF + 868
29 CoreFoundation 0x4dcdbbaa __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 10
30 CoreFoundation 0x4dcd7c00 __CFRunLoopRun + 1832
31 CoreFoundation 0x4dcd723a CFRunLoopRunSpecific + 370
32 GraphicsServices 0x50aebcd0 GSEventRunModal + 96
33 UIKitCore 0x65c91580 UIApplicationMain + 1730
34 libxpc.dylib 0x4da73c80 _xpc_objc_main.cold.3 + 152
35 libxpc.dylib 0x4da649b0 _xpc_objc_main + 184
36 libxpc.dylib 0x4da668c4 xpc_main + 110
37 Foundation 0x4e56b0c6 +[NSXPCListener serviceListener] + 0
38 PlugInKit 0x556d726c 0x556c5000 + 74348
39 WatchKit 0x5cfe9afe WKExtensionMain + 62
40 WatchKit 0x5d09f020 main + 10
Here's the position in the code that crashes:
required public init(from decoder: Decoder) throws {
let values = try decoder.container(keyedBy: CodingKeys.self)
self.id = try values.decode(String.self, forKey: .id)
do {
if values.contains(.groups) {
let groups = try values.decode(Dictionary<String, SonosGroup>.self, forKey: .groups)
self.groups = groups
}
if values.contains(.players) {
let players = try values.decode(Array<SonosPlayer>.self, forKey: .players)
self.players = players
}
}catch let error {
print("Error decoding groups \(error)")
}
}
For me this looks like an Apple bug and I filed feedback for it, but this is no solution for the next release.
Does anyone know what's the difference between a TestFlight build and an Xcode release build?
I tried setting a different optimization level, disabling bitcode (not allowed for Apple Watch Apps) and I started replacing Codable with the good old JSONSerialization.
If anyone knows more about it, thank you for that.
Kind regards
Alex
I was having a very similar problem with Encodable and Decodable's in a swift package. Setting DEAD_CODE_STRIPPING = NO in my apps target fixed it. This seems to be a weird leftover of this bug:
https://bugs.swift.org/browse/SR-11564?focusedCommentId=51285&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-51285
We see a sporadic crash in our user base, during a routine read from NSUserDefaults. The overwhelming majority of users don't experience this problem, and those that do aren't running any particular version of iOS. It seems to have appeared only since we started deploying with Xcode 9.1.
EXC_BAD_ACCESS KERN_PROTECTION_FAILURE 0x000000016efe3fc0
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x101816d4c #objc _NSContiguousString.length() + 5720
1 CoreFoundation 0x181e2a168 CFStringCompareWithOptionsAndLocale + 96
2 Foundation 0x1828602fc -[NSString isEqualToString:] + 76
3 CoreFoundation 0x181e19558 CFEqual + 596
4 CoreFoundation 0x181e15414 CFBasicHashFindBucket + 344
5 CoreFoundation 0x181e152a0 CFDictionaryGetValue + 224
6 CoreFoundation 0x181ef0c74 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 108
7 CoreFoundation 0x181f8f224 -[CFPrefsSource copyValueForKey:] + 64
8 CoreFoundation 0x181f992c0 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 40
9 CoreFoundation 0x181ef44f0 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:buttConfigurationURL:perform:]_block_invoke + 268
10 CoreFoundation 0x181ef3d0c normalizeQuintuplet + 356
11 CoreFoundation 0x181ef43d8 -[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:buttConfigurationURL:perform:] + 108
12 CoreFoundation 0x181f99258 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 124
13 CoreFoundation 0x181f9bbbc _CFPreferencesGetAppBooleanValueWithContainer + 136
14 Foundation 0x1828517a8 -[NSUserDefaults(NSUserDefaults) boolForKey:] + 112
15 <our code> 0x100d80750 #objc SettingsPersistence.persistedBool.getter (SettingsPersistence.swift:90)
Here's how we retrieve the value (Swift 3, called via Objective C):
fileprivate static let PersistedBoolKey = "persistedBool"
public var persistedBool: Bool {
get {
return UserDefaults.standard.bool(forKey: SettingsPersistence.PersistedBoolKey)
}
set(newPersistedBool) {
UserDefaults.standard.set(newPersistedBool, forKey: SettingsPersistence.PersistedBoolKey)
}
}
I thought it might be a thread issue, but this occurs on the main thread. Either way, NSUserDefaults is documented as completely thread-safe.
This looks to me like a low-level bug in Apple's libraries. What can I do to fix this problem on my end? Who should I report it to? Has anyone else experienced a similar problem?
Thank you!
This crash has disappeared ever since upgrading Xcode to 9.4.1.
I have a custom keyboard for iOS that uses Firebase for analytics. The Firebase app configuration is done at the initializer with a dispatch_once clause with the token as a global variable.
var token: dispatch_once_t = 0
class KeyboardViewController: UIInputViewController {
// ..
override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
dispatch_once(&token) {
FIRApp.configure()
} // line 90
}
// ..
}
This is working fine but I am receiving many crash reports that indicate crashes on many devices when the app is configured. I am stuck for days trying to figure out the cause. Here is a part of one of the crash reports stack trace:
Exception Type: EXC_CRASH (SIGQUIT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Quit: 3
Termination Reason: Namespace SIGNAL, Code 0x3
Terminating Process: launchd [1]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x000000018fab6338 __semwait_signal_nocancel + 8
1 libsystem_c.dylib 0x000000018f9e20dc nanosleep$NOCANCEL + 200 (nanosleep.c:104)
2 libsystem_c.dylib 0x000000018fa0568c sleep$NOCANCEL + 44 (sleep.c:62)
3 libsystem_dnssd.dylib 0x000000018fa6e7d4 ConnectToServer + 832 (dnssd_clientstub.c:607)
4 libsystem_dnssd.dylib 0x000000018fa6ff44 DNSServiceCreateConnection + 76 (dnssd_clientstub.c:1785)
5 libsystem_network.dylib 0x000000018fb2d318 __nw_resolver_set_update_handler_block_invoke + 872 (resolver.m:1031)
6 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
7 libdispatch.dylib 0x000000018f97e860 _dispatch_barrier_sync_f_invoke + 84 (queue.c:3457)
8 libsystem_network.dylib 0x000000018fb2ce78 nw_resolver_set_update_handler + 208 (resolver.m:1275)
9 SystemConfiguration 0x0000000190f8a16c __SCNetworkReachabilityRestartResolver + 260 (SCNetworkReachability.c:1711)
10 SystemConfiguration 0x0000000190f891c8 __SCNetworkReachabilitySetDispatchQueue + 764 (SCNetworkReachability.c:1823)
11 SystemConfiguration 0x0000000190f88ccc SCNetworkReachabilityScheduleWithRunLoop + 504 (SCNetworkReachability.c:1586)
12 CustomKeyboard 0x000000010013f630 -[FIRReachabilityChecker start] + 196
13 CustomKeyboard 0x000000010013abac -[FIRNetwork init] + 156
14 CustomKeyboard 0x0000000100132e28 -[FIRClearcutLogger init] + 416
15 CustomKeyboard 0x0000000100132c68 __35+[FIRClearcutLogger sharedInstance]_block_invoke + 36
16 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
17 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
18 CustomKeyboard 0x0000000100132c40 +[FIRClearcutLogger sharedInstance] + 108
19 CustomKeyboard 0x0000000100137214 +[FIRApp initClearcut] + 60
20 CustomKeyboard 0x0000000100136688 +[FIRApp configureDefaultAppWithOptions:sendingNotifications:] + 132
21 CustomKeyboard 0x000000010013643c +[FIRApp configure] + 316
22 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
23 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
24 CustomKeyboard 0x00000001000e314c _TFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 1500 (KeyboardViewController.swift:90)
25 CustomKeyboard 0x00000001000e3270 _TToFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 112 (KeyboardViewController.swift:0)
26 UIKit 0x00000001971f7688 -[_UIViewServiceViewControllerOperator __createViewController:withContextToken:fbsDisplays:appearanceSerializedRepresentations:legacyAppearance:traitCollection:initialInterfaceOrientation:hostAccessibilityServerPort:canShowTextServices:replyHandler:] + 2216 (UIViewServiceViewControllerOperator.m:1732)
27 CoreFoundation 0x0000000190aee160 __invoking___ + 144
28 CoreFoundation 0x00000001909e1c3c -[NSInvocation invoke] + 284 (NSForwarding.m:2948)
29 CoreFoundation 0x00000001909e66ec -[NSInvocation invokeWithTarget:] + 60 (NSForwarding.m:3019)
Apparently, the call trace after calling FIRApp.configure() is going through system libraries.
One observation from the stack trace is that the crash has something to do with checking the reachability of the device. However, I tried to reproduce a scenario where there is no internet connection but it's working fine.
Please note that all the crashes are happening on iOS 10 and most of them on iPhone 6.
Any help to figure out the cause of the crashes would be appreciated.
It is not recommended to use Firebase Analytics in an extension as the SDK does not support extension well. App extensions have limited functionalities compared to a full app so Firebase Analytics may not work well under some conditions, like the network in this case. The team is looking into supporting extensions better later.
It seems like the network is not available on custom keyboard as stated by Apple
"By default, a keyboard has no network access and cannot share a
container with its containing app. To enable these things, set the
value of the RequestsOpenAccess Boolean key in the Info.plist file to
YES. Doing this expands the keyboard’s sandbox, as described in
Designing for User Trust."
https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html#//apple_ref/doc/uid/TP40014214-CH16-SW1
i am writing an Application for iOS and apple watch and need to synchronize data between apple watch and iPhone.
I did this for sending dat from iPhone to apple watch mentioned like here: http://telliott.io/2015/08/11/how-to-communicate-between-ios-and-watchos2.html
The other way, if i change data on my watch app and send the updated data to my iPhone there is a weird warning if the ViewController, where the message is received, is opened. When it is closed and i send the updated data from my watch there is no warning on my console and the data gets updated if i open the ViewController:
2015-11-16 11:28:19.057 GeoSocialRecommender[286:11448] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release.
Stack:(
0 CoreFoundation 0x0000000182410f60 <redacted> + 148
1 libobjc.A.dylib 0x0000000196fc3f80 objc_exception_throw + 56
2 CoreFoundation 0x0000000182410e90 <redacted> + 0
3 Foundation 0x000000018342f2d8 <redacted> + 88
4 Foundation 0x00000001832b5a1c <redacted> + 56
5 Foundation 0x00000001832b15dc <redacted> + 260
6 UIKit 0x0000000187aab8c4 <redacted> + 64
7 UIKit 0x0000000187aac3dc <redacted> + 244
8 UIKit 0x000000018820b1e4 <redacted> + 268
9 UIKit 0x0000000187cb0f10 <redacted> + 176
10 UIKit 0x000000018799f7ac <redacted> + 644
11 QuartzCore 0x000000018719eb58 <redacted> + 148
12 QuartzCore 0x0000000187199764 <redacted> + 292
13 QuartzCore 0x0000000187199624 <redacted> + 32
14 QuartzCore 0x0000000187198cc0 <redacted> + 252
15 QuartzCore 0x0000000187198a08 <redacted> + 512
16 QuartzCore 0x00000001871c7b0c <redacted> + 236
17 libsystem_pthread.dylib 0x00000001979f61e0 <redacted> + 584
18 libsystem_pthread.dylib 0x00000001979f5d58 <redacted> + 136
19 libsystem_pthread.dylib 0x00000001979f553c pthread_mutex_lock + 0
20 libsystem_pthread.dylib 0x00000001979f5020 start_wqthread + 4
)
Anyone can help me with this weird warning?
This is the method where i get the message
func session(session: WCSession, didReceiveApplicationContext applicationContext: [String : AnyObject]){
if(WCSession.isSupported()){
self.prefs = Utils().importDataFromSession(prefs, applicationContext: applicationContext)
initializeGUI(true)
}
}
The WCSession header says:
/** ----------------------------- WCSessionDelegate -----------------------------
* The session calls the delegate methods when content is received and session
* state changes. All delegate methods will be called on the same queue. The
* delegate queue is a non-main serial queue. It is the client's responsibility
* to dispatch to another queue if neccessary.
*/
So if you want to update the UI you need to make sure that code runs on the application's main thread; so make the following change to your code and the warning will go away:
func session(session: WCSession, didReceiveApplicationContext applicationContext: [String : AnyObject]){
if (WCSession.isSupported()) {
self.prefs = Utils().importDataFromSession(prefs, applicationContext: applicationContext)
dispatch_async(dispatch_get_main_queue(), {
initializeGUI(true)
})
}
}
I am usually able to solve the crashes but here I have not clue from where it comes from.
I use parse, and I am simply doing a request in background with a completion block.
The app crashes at a simple if condition and I can barely identify anything, no way to print description, ...
Do you have any idea ? A starting point ? anything ?
Xcode 6.1 is really strange, it seems that the debugger is buggy.
Here is the log of the crash :
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x000000019657a964 __kill + 8
1 MyAPP 0x00000001001f2b70 0x10009c000 + 1403760
2 libsystem_platform.dylib 0x0000000196610958 _sigtramp + 64
3 MyAPP 0x00000001001318cc 0x10009c000 + 612556
4 MyAPP 0x000000010013797c 0x10009c000 + 637308
5 MyAPP 0x0000000100135fc4 0x10009c000 + 630724
6 MyAPP 0x00000001002e408c 0x10009c000 + 2392204
7 MyAPP 0x00000001001dbf78 0x10009c000 + 1310584
8 libdispatch.dylib 0x00000001964393a8 _dispatch_call_block_and_release + 20
9 libdispatch.dylib 0x0000000196439368 _dispatch_client_callout + 12
10 libdispatch.dylib 0x000000019643d97c _dispatch_main_queue_callback_4CF + 928
11 CoreFoundation 0x000000018566d69c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
12 CoreFoundation 0x000000018566b744 __CFRunLoopRun + 1488
13 CoreFoundation 0x00000001855991f0 CFRunLoopRunSpecific + 392
14 GraphicsServices 0x000000018e7275a0 GSEventRunModal + 164
15 UIKit 0x0000000189eca780 UIApplicationMain + 1484
16 Shuff 0x0000000100129474 0x10009c000 + 578676
17 libdyld.dylib 0x0000000196462a04 start + 0
And here is a sample of the iOS code :
var query = PFQuery(className: "_User")
query.whereKey("facebookId", containedIn: ids)
query.findObjectsInBackgroundWithBlock(){
results, error in
if var resultsvar = results? {
self.functionToCall(resultsvar)
}
}
and the functionToCall crashes.
Maybe this can help :
0 0x00000001001679c8 in specialization of Swift._ArrayBuffer._nonNative.getter : Swift.Optional [inlined] ()
Yes !!! The debugger is not working well ! I was able to find the correct lines by doing the following : put a breakpoint at the start of where you think the app crashes, go step by step, remember the lowest line you've gone through. Even if the debugger crashes on another the line, the line you are looking for is probably the lowest one.
This is just a guess but I was working on something similar and I think you need to change this code to:
query.findObjectsInBackgroundWithBlock(){
results?, error? in
if var resultsvar = results {
self.functionToCall(resultsvar)
}
}
Note that I made both results and error optional. In my case I was providing a block defined in Obj-C, and in Obj-C these objects can legally be == nil. So I think you have to define them as optionals in Swift.