单元测试用例之间的零星崩溃重置持久存储（RestKit）

Question

我提前道歉，这可能最终不会对这里的一般知识库做出太大贡献，但我正在寻求帮助，以诊断可能导致我的单元测试偶尔崩溃的配置疏忽。

我在单元测试时使用带有内存对象存储的 RestKit 进行设置，因此在每个测试用例之后，我可以重置我的持久存储，并且每个测试都可以使用新的数据库运行。大部分时间我的测试套件运行没有问题，但通常足以破坏交易，[我认为]似乎过度释放托管对象上下文会导致崩溃。以下所有相关代码和崩溃数据：

单元测试基类设置

@implementation MyTestCase

- (void)setUp
{
    [super setUp];

    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        [[MyObjectManager sharedManager] start];
    });
}

- (void)tearDown
{
    [super tearDown];

    [[MyObjectManager sharedManager] reset];
}

相关的 MyObjectManager 设置

@interface MyObjectManager : RKObjectManager

- (void)start
{
    RKManagedObjectStore *managedObjectStore = [[RKManagedObjectStore alloc] initWithPersistentStoreCoordinator:[self persistentStoreCoordinator]];
    self.managedObjectStore = managedObjectStore;
    [managedObjectStore createManagedObjectContexts];

    [RKManagedObjectStore setDefaultStore:managedObjectStore];
}

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator
{
    if (_persistentStoreCoordinator != nil)
    {
        return _persistentStoreCoordinator;
    }

    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:kRDPersistentStore];

    _persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];

    NSDictionary *options = @{
                              NSSQLitePragmasOption : @{
                                      @"synchronous" : @"FULL",
                                      @"fullfsync" : @(1)
                                      },
                              NSMigratePersistentStoresAutomaticallyOption : @YES,
                              NSInferMappingModelAutomaticallyOption : @YES
                              };

    NSError *error = nil;
    if (![self persistentStoreAtPath:storeURL options:options error:error])
    {
        NSLog(@"Error adding store %@: %@, %@", storeURL, error, [error userInfo]);
        // Additional handling
    }

    return _persistentStoreCoordinator;
}

- (NSPersistentStore *)persistentStoreAtPath:(NSURL *)storeURL options:(NSDictionary *)options error:(NSError *)error
{
    // (NSSQLiteStoreType and storeUrl are used if we're not unit testing)
    return [_persistentStoreCoordinator addPersistentStoreWithType:NSInMemoryStoreType
                                                     configuration:nil
                                                               URL:nil
                                                           options:options
                                                             error:&error];
}

MyObjectManager::reset 实现

- (void)reset
{
    [[RKObjectManager sharedManager].operationQueue cancelAllOperations];

    NSError *error = nil;
    [[RKManagedObjectStore defaultStore] resetPersistentStores:&error];

    if (error)
    {
        NSLog(@"Error! : %@", error);
    }

    [[NSURLCache sharedURLCache] removeAllCachedResponses];
}

典型的崩溃报告

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
iPhone Simulator 463.9.41, iPhone OS 7.1 (iPhone Retina (4-inch)/11D167)

主线程正在旋转运行循环，等待异步测试用例： （并非总是如此，但我们的大多数测试都采用这种方法）

Thread : com.apple.main-thread
0  libsystem_kernel.dylib         0x047f6f92 semaphore_signal_trap + 10
1  libdispatch.dylib              0x0447f41f _dispatch_barrier_sync_f_slow_invoke + 54
2  libdispatch.dylib              0x044904d0 _dispatch_client_callout + 14
3  libdispatch.dylib              0x0447e726 _dispatch_main_queue_callback_4CF + 340
4  CoreFoundation                 0x040fb43e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
5  CoreFoundation                 0x0403c5cb __CFRunLoopRun + 1963
6  CoreFoundation                 0x0403b9d3 CFRunLoopRunSpecific + 467
7  CoreFoundation                 0x0403b7eb CFRunLoopRunInMode + 123
8  Foundation                     0x03a71e35 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 284
9  Foundation                     0x03a71cd5 -[NSRunLoop(NSRunLoop) runUntilDate:] + 88
10 Remind101-Tests                0x0cbb2c02 -[UTTestCase waitForBlockWithTimeout:] + 233
11 Remind101-Tests                0x0cbb2b14 -[UTTestCase waitForBlock] + 49
12 Remind101-Tests                0x0cbba55e -[UTAPITestCase sendRequestExpectingSuccess:] + 142
13 Remind101-Tests                0x0cb92832 -[UTMessageRequestTests testRequestCreatesFileEntities] + 166
14 CoreFoundation                 0x0408a91d __invoking___ + 29
15 CoreFoundation                 0x0408a82a -[NSInvocation invoke] + 362
16 XCTest                         0x20103c6c -[XCTestCase invokeTest] + 221
17 XCTest                         0x20103d7b -[XCTestCase performTest:] + 111
18 otest-shim-ios.dylib           0x0098fcc7 XCPerformTestWithSuppressedExpectedAssertionFailures + 172
19 otest-shim-ios.dylib           0x0098fc15 XCTestCase_performTest + 31
20 XCTest                         0x20104c48 -[XCTest run] + 82
21 XCTest                         0x201033e8 -[XCTestSuite performTest:] + 139
22 XCTest                         0x20104c48 -[XCTest run] + 82
23 XCTest                         0x201033e8 -[XCTestSuite performTest:] + 139
24 XCTest                         0x20104c48 -[XCTest run] + 82
25 XCTest                         0x201033e8 -[XCTestSuite performTest:] + 139
26 XCTest                         0x20104c48 -[XCTest run] + 82
27 XCTest                         0x201066ba +[XCTestProbe runTests:] + 183
28 Foundation                     0x03a4b5ec __NSFireDelayedPerform + 372
29 CoreFoundation                 0x04054ac6 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
30 CoreFoundation                 0x040544ad __CFRunLoopDoTimer + 1181
31 CoreFoundation                 0x0403c538 __CFRunLoopRun + 1816
32 CoreFoundation                 0x0403b9d3 CFRunLoopRunSpecific + 467
33 CoreFoundation                 0x0403b7eb CFRunLoopRunInMode + 123
34 GraphicsServices               0x057495ee GSEventRunModal + 192
35 GraphicsServices               0x0574942b GSEventRun + 104
36 UIKit                          0x01e7ff9b UIApplicationMain + 1225
37 Remind101                      0x0008d184 main (main.m:16)
38 libdyld.dylib                  0x046c5701 start + 1

NSManagedObjectContext 队列线程崩溃：

Thread : Crashed: NSManagedObjectContext Queue
0  libobjc.A.dylib                0x03e250be objc_msgSend + 26
1  CoreData                       0x0108ffe3 developerSubmittedBlockToNSManagedObjectContextPerform_privateasync + 83
2  libdispatch.dylib              0x044904d0 _dispatch_client_callout + 14
3  libdispatch.dylib              0x0447e047 _dispatch_queue_drain + 452
4  libdispatch.dylib              0x0447de42 _dispatch_queue_invoke + 128
5  libdispatch.dylib              0x0447ede2 _dispatch_root_queue_drain + 78
6  libdispatch.dylib              0x0447f127 _dispatch_worker_thread2 + 39
7  libsystem_pthread.dylib        0x047bfdab _pthread_wqthread + 336
8  libsystem_pthread.dylib        0x047c3cce start_wqthread + 30

崩溃线程的堆栈有微小的变化，但它总是在最后几帧中包含developerSubmittedBlockToNSManagedObjectContextPerform_privateasync，然后是错误的objc_msgSend。

我最初的假设是我的代码库中的某些东西正在从主线程之外访问MyObjectManager.managedObjectContext，据我所知，这将是一个糟糕的时期。但是我设置了一个条件来记录并暂停，如果访问器是从一个不是主线程的线程调用的，而主线程从未被命中，所以我在那个线程上实现了我唾手可得的果实。

我还尝试将一些日志记录到 RestKit 库中异步 NSManagedObjectContext::performBlock 函数实例的入口和出口点，以查看块运行时间是否比预期长，保持对上下文的引用并取消引用它在它被摧毁之后。如果这是问题所在，我会期待一个没有退出日志的进入日志，但我没有看到。我没有对performBlockAndWait 进行相同的尝试，因为我假设在我的测试用例完成并重置持久存储时所有同步操作都已完成。

我真的不知道如何继续对此进行调查。我知道这不是一件很重要的事情，但如果有人有任何想法或建议来追踪这个问题，我很乐意提供更多信息并尝试任何事情来解决这个问题。

Answer 1

developerSubmittedBlockToNSManagedObjectContextPerform_privateasync 的实际作用如下：

1. 从队列中获取对托管对象上下文的引用
2. 创建自己的自动释放池
3. 执行块
4. 在托管对象上下文上调用 _processRecentChanges: 以处理任何待处理的用户事件
5. 排空自动释放池
6. 释放块（块在传递给此方法之前被复制）

如果此时块为 NULL，那将是一个问题，但您会有不同的症状。这里唯一会使用objc_msgSend 的是自动释放池和发给_processRecentChanges: 的消息。

你可以尝试在-[NSManagedObjectContext _processRecentChanges:] 上设置一个符号断点，看看是否能给你任何线索。 RestKit 很可能对托管对象上下文的生命周期做出了一些无效的假设，并且在您的情况下它已经过时了。如果这是真的，那么其他地方也可能出现相反的错误——上下文被过度保留。这两个问题往往是齐头并进的。您的问题不包括报告的崩溃原因（异常、EXC_BAD_ACCESS 等），因此很难确定。

_processRecentChanges: 经常被调用，因此可能仍需要一些时间来追踪它。使用较新的开发人员工具可以更轻松地解决问题 - 您应该能够查看提交崩溃块的内容以及来自哪个队列，并且您应该能够将 Instruments 与您的测试用例一起使用。如果您可以使用更新的工具重现此问题，您可能会更快地进行故障排除。