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 Implementation

- (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实际做的事情：

从队列
创建自己的自动释放池
执行块
在托管对象上下文上调用_processRecentChanges:以处理任何待处理的用户事件
排出自动释放池
释放块（块在传递给此方法之前被复制）

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

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

_processRecentChanges:被大量调用，因此可能还需要一些时间来跟踪此情况。使用较新的开发人员工具可以更容易地解决问题 - 您应该能够看到提交崩溃块的内容以及从哪个队列中提取，并且您应该能够将Instruments与您的测试用例一起使用。如果您可以使用更新的工具重现这一点，那么您可以更快地对其进行故障排除。

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

1 个答案: