ios - 在单元测试用例 (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

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

我最初的假设是我的代码库中的某些东西正在从主线程访问 MyObjectManager.managedObjectContext，据我所知这将是一个糟糕的时刻。但是，如果从非主线程的线程调用访问器时，我设置了一个记录和暂停的条件，该线程从未被命中，所以我在那个线程上实现了我的目标。

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

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

Answer 1

下面是 developerSubmittedBlockToNSManagedObjectContextPerform_privateasync 实际做的事情:

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

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

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

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