Nklibrary在iOS 11.3中的Init上崩溃



我们仍然有一些旧的 NewsstandKit代码,这些代码已经在几年中没有更新。

由于某种原因,自2017年以来一直在商店中的应用程序的版本现在正在使用iOS 11.3碰撞,这似乎是当我们在应用程序启动时首次致电[NKLibrary sharedLibrary]时引起的。

stackTraces指向NewsstandKit中深处的网络调用。

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000
Crashed: com.apple.main-thread
0  CoreFoundation                 0x1810b63d4 CFBooleanGetValue + 80
1  CFNetwork                      0x181823944 URLRequest::initialize(long, void const**, long, __CFDictionary const*) + 328
2  CFNetwork                      0x1817d7298 _CFURLRequestCreateFromArchiveList + 136
3  CFNetwork                      0x18195bfd4 -[NSURLRequest initWithCoder:] + 1660
4  Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
5  Foundation                     0x181b9fa88 _decodeObject + 308
6  Foundation                     0x181b2e8bc -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 432
7  NewsstandKit                   0x1a24031a4 -[NKAssetDownload initWithCoder:] + 216
8  Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
9  Foundation                     0x181b4d010 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1388
10 Foundation                     0x181b53c54 -[NSArray(NSArray) initWithCoder:] + 220
11 Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
12 Foundation                     0x181b9fa88 _decodeObject + 308
13 Foundation                     0x181b2e8bc -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 432
14 NewsstandKit                   0x1a2401a08 -[NKIssue initWithCoder:] + 316
15 Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
16 Foundation                     0x181b4d010 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1388
17 Foundation                     0x181b53c54 -[NSArray(NSArray) initWithCoder:] + 220
18 Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
19 Foundation                     0x181b4d010 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1388
20 Foundation                     0x181b4d340 -[NSDictionary(NSDictionary) initWithCoder:] + 224
21 Foundation                     0x181ba01e8 _decodeObjectBinary + 1720
22 Foundation                     0x181b9fa88 _decodeObject + 308
23 Foundation                     0x181b2e8bc -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 432
24 Foundation                     0x181bcac84 -[NSCoder(Exceptions) __tryDecodeObjectForKey:error:decodeBlock:] + 80
25 Foundation                     0x181bca9e4 -[NSCoder decodeTopLevelObjectOfClasses:forKey:error:] + 92
26 Foundation                     0x181c088e4 +[NSKeyedUnarchiver(NSKeyedUnarchiverSecureCodingInitializers) unarchivedObjectOfClasses:fromData:error:] + 140
27 NewsstandKit                   0x1a240042c -[NKLibrary _load] + 272
28 NewsstandKit                   0x1a23fe8b8 -[NKLibrary init] + 568
29 NewsstandKit                   0x1a23fe628 __26+[NKLibrary sharedLibrary]_block_invoke + 92
30 libdispatch.dylib              0x180ae0ae4 _dispatch_client_callout + 16
31 libdispatch.dylib              0x180ae42ec dispatch_once_f$VARIANT$mp + 60
32 NewsstandKit                   0x1a23fe5c8 +[NKLibrary sharedLibrary] + 112
33 MY_APP                         0x1007d29e4 -[MYAPPCLASS MYAPPMETHOD] (MYFILE.m:90)

第33行是我们调用[NKLibrary sharedLibrary].currentlyReadingIssue的点,这就是我们现在获取的所有信息。这似乎是在应用程序启动之后发生的,但是没有信息在背景或前景中触发。

只是好奇是否有人看过这个?我唯一的想法是我们需要删除NewsstandKit

我就此与Apple开发人员的技术支持联系。我收到了非常完整的回复。

我的理解是:

  • 这是iOS 11.3报摊中的错误。
  • 它影响了在升级到iOS 11.3
  • 的点上下载报摊资产的用户
  • 只能通过删除其应用程序并重新安装的用户来修复它。苹果可能会在iOS 11.4中解决该错误,这可能会使它们免于"死亡环",但在那之前,重新安装是唯一的选择。

苹果的响应,对标记进行了轻微编辑:

我从您的错误(2018-04-12_08-08-18.4485_+0100-41f4ffc57b5f5e16c05c0baaa6a426ff9321cdb5.crash(中抓住了崩溃报告,并深入了外观。首先,这是崩溃回溯的编辑版本:

框架37正在调用您的代码。
帧36到34是您的代码启动报摊套件。
框架33至30是+[NKLibrary sharedLibrary]做单程的事情。
框架29和28是NKLibrary的初始评估器。显然,这可以通过不合理的钥匙档案(帧27到5(来完成其大部分工作。
最后,帧4表示库中的一个对象是NSURLRequest,并且导致撞车框架的帧, 帧0,是通常的NSURLRequest解码逻辑。

基于上述内容,我开始研究NKLibrary如何处理其归档和不合理的。虽然这样做,但我偶然发现了我认为这是此错误的根本原因,也就是说,在11.3中,我们更新了报摊套件以将其用于其库34837823>的安全编码。通常,这是一件好事,但是它似乎已经在NSURLRequest中的安全编码支持中暴露了潜在问题。

考虑附加的测试项目(Test39132525(。它有两个按钮:

  • 保存不安全创建一个简单的键合档案,包含NSURLRequest

  • 加载安全尝试使用安全编码器加载。

如果您以明显的方式运行它(运行,保存,加载(,它会以这样的回溯崩溃:

Thread 6 Crashed:
0  … CFBooleanGetValue + 80 (CFInternal.h:713)
…
4  … -[NSURLRequest initWithCoder:] + 1660 (NSURLRequest.mm:280)
5  … _decodeObjectBinary + 1720 (NSKeyedArchiver.m:2391)
…
27 … +[NSKeyedUnarchiver(NSKeyedUnarchiverSecureCodingInitializers) unarch…
28 … -[NKLibrary _load] + 272 (NKLibrary.m:470)
29 … -[NKLibrary init] + 568 (NKLibrary.m:108)
30 … __26+[NKLibrary sharedLibrary]_block_invoke + 92 (NKLibrary.m:75)
31 … _dispatch_client_callout + 16 (object.m:507)
32 … dispatch_once_f$VARIANT$mp + 60 (once.c:63)
33 … +[NKLibrary sharedLibrary] + 112 (once.h:84)
34 … static NewsstandUtilities.allIssues() + 36 (NewsstandUtilities.swift:…
35 … closure #1 in static NewsstandIOUtility.deleteAllLegacyImagesFromExis…
36 … thunk for @callee_owned () -> () + 36 (WelcomeViewController.swift:0)
37 … _dispatch_call_block_and_release + 24 (init.c:994)
…

看起来很熟悉,嗯?

我相信这是您的用户发生的事情:

  1. 他们在11.2.6上运行您的应用程序,并具有主动下载的活动资产。结果是NKLibrary保存了一个不安全的键盘档案,其中包含NSURLRequest

  2. 他们更新为11.3。

  3. NKLibrary试图安全地加载其存档,以崩溃。

大多数用户都看不到这一点,因为他们在11.2.6中没有主动下载,因此键控存档不包含NSURLRequest

我已经要求CFNETWORK ENGINEERING查看他们是否可以更早而不是晚些时候获得此修复。根据对话的方式,我可能会或可能不会与报摊套件聊天,以了解他们对潜在解决方法的看法。

检查文档,以查看新闻包的工作方式是否发生了变化。从文档中,sharedLibrary看起来可以返回与您看到的崩溃对齐的nil。

sharedLibrary

返回代表报摊的共享实例 内容库。

返回值

nklibrary类的单例实例或 nil 无法创建实例。

最新更新