试图找到我在生产版本中看到的问题的底部,并且FINALLY能够在测试时重现它。使用RestKit v0.23.1,当使用以下代码执行RKManagedObjectRequestOperation时(插入仪器时)我得到“一个Objective-C消息被发送到一个解除分配的'NSError'对象(僵尸)”并且每次有对象时应用程序崩溃响应JSON - 如果响应类似于“objects =();”没有崩溃 - 所以我猜它在RestKit /核心数据映射或存储中的某个地方?
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中正确记录,但永远不会到达成功和错误块内的日志。这是我从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
答案 0 :(得分:3)
这不是RestKit的问题。我经常看到这个问题,实际上看起来过度释放实际上发生在Apple的代码中。当您尝试保存到Core Data存储并且失败时,会发生此问题。核心数据报告错误,但错误处理错误。
我有一些导致保存失败的情况,这就是我修复它们的方法:
由于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:@&#34; ok&#34;]
来判断事情是好的。