ios - 回到前台引用对plist文件的写入操作时，Adobe iOS SDK崩溃

Question

我在重现下面详细介绍的崩溃时遇到了麻烦(从崩溃分析/跟踪中获取了它)。在报告的每个崩溃实例中，似乎总是同时有另一个看上去可疑的线程与崩溃的线程同时运行:

断线

0   CoreFoundation 0x2f9074be CFGetTypeID + 6
1   CoreFoundation 0x2f91e47b _flattenPlist + 47
2   CoreFoundation 0x2f91e57f _flattenPlist + 307
3   CoreFoundation 0x2f98257b __CFBinaryPlistWrite + 131
4   CoreFoundation 0x2f91e321 CFPropertyListWrite + 245
5   CoreFoundation 0x2f92e731 CFPropertyListWriteToStream + 145
6   CoreFoundation 0x2f92c39d _CFXPreferencesWritePlist + 269
7   CoreFoundation 0x2f92c28b -[CFXPreferencesPropertyListSourceSynchronizer writePlistToDisk] + 131
8   CoreFoundation 0x2f929aef -[CFXPreferencesPropertyListSourceSynchronizer synchronizeAlreadyFlocked] + 487
9   CoreFoundation 0x2f929905 -[CFXPreferencesPropertyListSourceSynchronizer synchronize] + 21
10  CoreFoundation 0x2f929405 __79-[CFXPreferencesPropertyListSource synchronizeInBackgroundWithCompletionBlock:]_block_invoke + 101
11  libdispatch.dylib 0x3a656d53 _dispatch_call_block_and_release + 11
12  libdispatch.dylib 0x3a65bcbd _dispatch_queue_drain + 489
13  libdispatch.dylib 0x3a658c6f _dispatch_queue_invoke + 43
14  libdispatch.dylib 0x3a65c5f1 _dispatch_root_queue_drain + 77
15  libdispatch.dylib 0x3a65c8dd _dispatch_worker_thread2 + 57
16  libsystem_pthread.dylib 0x3a787c17 _pthread_wqthread + 299
17  libsystem_pthread.dylib 0x3a787adc start_wqthread + 8

其他可疑线程(总是同时运行，并且看起来像相关的线程):

0   libsystem_kernel.dylib 0x3a70faa0 semaphore_wait_trap + 8
1   libdispatch.dylib 0x3a65b513 _dispatch_barrier_sync_f_slow + 139
2   CoreFoundation 0x2f94424d CFPreferencesAppSynchronize + 265
3   Foundation 0x3032e91d -[NSUserDefaults(NSUserDefaults) synchronize] + 25
4   MailOnline 0x00280897 ADBLifecycleStart + 2495
5   CoreFoundation 0x2f998f41 _CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 13
6   CoreFoundation 0x2f90cda9 _CFXNotificationPost + 1721
7   Foundation 0x302f7cc5 -[NSNotificationCenter postNotificationName:object:userInfo:] + 73
8   UIKit 0x3246747f -[UIApplication _sendWillEnterForegroundCallbacks] + 155
9   UIKit 0x3240c88b -[UIApplication _handleApplicationResumeEvent:] + 927
10  UIKit 0x3220b613 -[UIApplication handleEvent:withNewEvent:] + 1883
11  UIKit 0x3220adf9 -[UIApplication sendEvent:] + 73
12  UIKit 0x3226f405 _UIApplicationHandleEvent + 617
13  GraphicsServices 0x34878b55 _PurpleEventCallback + 609
14  GraphicsServices 0x3487873f PurpleEventCallback + 35
15  CoreFoundation 0x2f9a1847 _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
16  CoreFoundation 0x2f9a17e3 __CFRunLoopDoSource1 + 347
17  CoreFoundation 0x2f99ffaf __CFRunLoopRun + 1407
18  CoreFoundation 0x2f90a769 CFRunLoopRunSpecific + 525
19  CoreFoundation 0x2f90a54b CFRunLoopRunInMode + 107
20  GraphicsServices 0x348776d3 GSEventRunModal + 139
21  UIKit 0x32269891 UIApplicationMain + 1137
22  MailOnline 0x000cd18b main (main.m:16)
23  libdyld.dylib 0x3a66bab7 start + 3

在调试正在运行的程序时，似乎我们用于跟踪的Adobe Mobile SDK会监听OS触发的返回前台事件，然后在NSUserDefaults上调用sync(请参阅其他可疑线程)。然后，同步中断到另一个线程(崩溃的线程)中，但是随后由于尝试写入plist文件的某种原因而崩溃。

我无法重现崩溃。我们正在使用Adobe Mobile Library iOS SDK v4.0，因此，如果其他人在使用这些SDK时发生了类似的崩溃，请提供帮助!或者，如果有人对如何使崩溃更可能发生的步骤有任何建议(例如，我尝试在SDK运行时尝试不断写plist，以查看这是否是线程问题但没有运气)，请提出建议...

注意:在运行iOS 7的较新设备上仍然会发生此问题，但在运行iOS 8.0或8.1的设备上仍然不会发生此问题。

Answer 1

此问题是由于NSUserDefaults本身内部的争用条件引起的。以下代码段将在单独的场景中重现该问题(您需要让此代码运行15-30秒以暴露该问题):

dispatch_async(dispatch_get_main_queue(), ^{
        while(true) {
            for(int i = 0; i < 20000; i++) {
                [[NSUserDefaults standardUserDefaults] setObject: @"value" forKey: [NSString stringWithFormat: @"blah%d",i]];
            }
            for(int i = 0; i < 20000; i++) {
                [[NSUserDefaults standardUserDefaults] removeObjectForKey: [NSString stringWithFormat: @"blah%d",i]];
            }
        }
    });

其他人已经报告了此问题，最清楚的例子是在Apple开发者论坛上的 this post(需要注册)。

我的建议是检查您的代码是否存在对NSUserDefaults的任何重大读/写周期。如果需要对数据进行大量更改或更新，则可能要滚动自己的持久层而不是NSUserDefaults，直到Apple解决此问题为止。

在这种情况下，ADBLifecycleStart方法是一个重头戏。这段代码在自己的队列上运行，并且大多数时候都可能存在(或至少被完整的线程转储捕获)。在最坏的情况下，ADBLifeCycleStart方法对NSUserDefaults进行总共13次写入，然后进行同步。