SBNotificationHub 仅在 Testflight Beta 构建分发中从 registerTemplateWithDeviceToken 返回时崩溃

Posted 2023-02-24

【中文标题】SBNotificationHub 仅在 Testflight Beta 构建分发中从 registerTemplateWithDeviceToken 返回时崩溃

【英文标题】：SBNotificationHub crash on return from registerTemplateWithDeviceToken in Testflight Beta build distribution only

【发布时间】：2015-02-13 09:34:03

【问题描述】：

如果我禁用应用程序的通知，我不会同步并且应用程序运行良好。如果它们已启用，并且代码注意到并尝试同步 - 它就会崩溃。

应用程序已经 100% 正常运行了数周，没有任何代码更改。想知道在同一测试设备上相同版本的方案之间切换是否是一件麻烦事。

使用从 Xcode 到设备的相同非调试/生产方案运行良好。但是通过官方存档构建的 Testflight 应用程序安装它会崩溃。很奇怪。

有什么见解吗？

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

这是 1.2.4 版本的 Windows Messaging Azure SDK

编辑：也是 v2.0

【问题讨论】：

这似乎仅限于我的设备。我很快就会在 Azure 上调试我的详细信息

我可以看到使用 charles 作为代理连接到 https://.servicebus.windows.net:443 的连接尝试，但请求/响应已加密。

如果我通过 charlesproxy.com/documentation/proxying/ssl-proxying 启用 SSL 代理，请求现在会失败，并且应用程序不会崩溃。所以从初始请求中从 Azure 返回的东西肯定会导致他们的 SDK 崩溃

【参考方案1】：

编辑：我追踪到this line of code，我相信它会因为nil template name 而倒下。在我也与集线器交互的服务器代码中，我没有传递template name，所以它被取消了。但仅此一项并不会导致崩溃。有一个我还没有发现的情况是设备 ID 发生变化或类似情况，这正在使这个表面出现。等我弄清楚什么时候更新。

编辑 2：对于经历过这种情况的少数用户，他们在 Azure 中的数据的共同特征，正如上面的代码所暗示的那样，是缺少 @987654324 @。可以通过传递一个 nil 名称来手动强制崩溃：

[hub registerTemplateWithDeviceToken:deviceToken 
                                name:nil 
                    jsonBodyTemplate:alertTemplate 
                      expiryTemplate:@"0" 
                                tags:[NSSet setWithArray:tags] 
                          completion:^(NSError* error) 

我不知道 Azure 发生了什么，因此使用有效字符串 name 的调用没有更新 Azure 数据并返回有效值，但我的直觉是Azure 端的竞争条件和错误。

我们现在正在爬取 Azure 中的注册用户数据并修复 nil 模板名称，我们已经验证这可以解决陷入这种悲伤循环的用户的问题。

更新 - 这确实是修复。自从纠正了错误的用户模板数据以来，还没有发生过崩溃。

原答案： 不是一个非常令人满意的解决方案，但我禁用了应用程序的通知（通过操作系统设置），使用该应用程序取消订阅我订阅的所有标签（很多）。然后重新启用通知，崩溃不再发生。

现在我的生产 Xcode 方案和测试飞行安装都导致相同的设备 ID。这似乎不是问题的根源，但谁知道呢。知道 SDK 在崩溃时试图坚持什么会非常有趣 - 这将是找出发生了什么的最可靠方法。