RestKit核心数据NSError dealloc崩溃
试图深入到我在生产版本中看到的问题的底部，最终在testing时能够重现它。 使用RestKit v0.23.1，当使用下面的代码（插入到乐器中）执行RKManagedObjectRequestOperation时，我得到“一个Objective-C消息被发送到一个释放的'NSError'对象（僵尸）”，并且每次有对象时应用程序崩溃响应JSON – 如果响应类似于“objects =（）;” 没有崩溃 – 所以我猜测它在RestKit / Core Data映射或存储中的某处？
RKManagedObjectRequestOperation *objectRequestOperation = [_objectManager managedObjectRequestOperationWithRequest:request managedObjectContext:_objectManager.managedObjectStore.mainQueueManagedObjectContext success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) { DDLogInfo(@"INSIDE SUCCESS BLOCK"); } failure:^(RKObjectRequestOperation *operation, NSError *error) { DDLogInfo(@"INSIDE ERROR BLOCK"); }]; [objectRequestOperation setWillMapDeserializedResponseBlock:^id(id deserializedResponseBody) { DDLogInfo(@"Response JSON: %@", deserializedResponseBody); return deserializedResponseBody; }]; objectRequestOperation.savesToPersistentStore = YES; [objectRequestOperation start]; 原始JSON在setWillMapDeserializedResponseBlock中正确logging，但成功和错误块内的日志永远不会到达。 这里是我从crashlytics得到的堆栈跟踪：
Thread : Crashed: NSOperationQueue Serial Queue 0 libobjc.A.dylib 0x37dd4626 objc_msgSend + 5 1 Foundation 0x2df5802d -[NSError dealloc] + 60 2 libobjc.A.dylib 0x37dd9b6b objc_object::sidetable_release(bool) + 174 3 libobjc.A.dylib 0x37dda0d3 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358 4 CoreFoundation 0x2d569501 _CFAutoreleasePoolPop + 16 5 Foundation 0x2df69999 -[__NSOperationInternal _start:] + 1064 6 Foundation 0x2e00d745 __NSOQSchedule_f + 60 7 libdispatch.dylib 0x382b8cbd _dispatch_queue_drain + 488 8 libdispatch.dylib 0x382b5c6f _dispatch_queue_invoke + 42 9 libdispatch.dylib 0x382b95f1 _dispatch_root_queue_drain + 76 10 libdispatch.dylib 0x382b98dd _dispatch_worker_thread2 + 56 11 libsystem_pthread.dylib 0x383e4c17 _pthread_wqthread + 298
这不是RestKit的问题。 我经常看到这个问题，它实际上看起来像苹果的代码实际发生过度释放。 当您尝试保存到Core Data存储并且失败时，会发生此问题。 核心数据应该报告错误，但error handling不当。
我有几个情况导致保存失败，这是我如何修复它们：
由于Data Protection API，数据存储不可访问。
无论是忙等待，让你的应用程序无法启动像这样：
while(![[UIApplication sharedApplication] isProtectedDataAvailable]) { [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.5f]]; }
或者，如果商店中的数据不像这样敏感，请停用保护措施：
[_coordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:url options:@{NSPersistentStoreFileProtectionKey:NSFileProtectionNone} error:&error];
重要的是，您不能尝试保存，直到您可以访问该文件。 如果你可以重新构造你的代码，以防止访问数据库时，它是不可访问的也是好的。 您可以使用Data Protection API应用程序委托方法触发该机制。
数据存储已损坏 – 此处最好的做法是删除存储并重新开始。 这是一个很好的方法来直接检测使用sqlite库损坏的商店。
#import <sqlite3.h> sqlite3 *dbConnection; if (sqlite3_open([[url absoluteString] UTF8String], &dbConnection) != SQLITE_OK) { NSLog(@"[SQLITE] Unable to open database!"); } sqlite3_stmt *statement = nil; sqlite3_prepare_v2(dbConnection, "PRAGMA quick_check;", -1, &statement, NULL); NSString *result = nil; while (sqlite3_step(statement) == SQLITE_ROW) { for (int i=0; i<sqlite3_column_count(statement); i++) { int colType = sqlite3_column_type(statement, i); if (colType == SQLITE_TEXT) { const unsigned char *col = sqlite3_column_text(statement, i); result = [NSString stringWithFormat:@"%s", col]; } else { NSLog(@"[SQLITE] UNKNOWN DATATYPE"); } } } sqlite3_close(dbConnection);
这运行一个sqlite PRAGMA查询来执行完整性检查。 我使用quick_check，但如果您愿意等待额外的时间，也可以使用integrity_check。 你可以用[result isEqualToString：@“ok”]告诉事情是好的]