SBNotificationHub crash on return from registerTemplateWithDeviceToken in Testflight Beta build distribution only

问题

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

回答1:

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.

来源：https://stackoverflow.com/questions/28496401/sbnotificationhub-crash-on-return-from-registertemplatewithdevicetoken-in-testfl