RestKit核心数据NSError dealloc崩溃

时间:2014-05-09 21:59:21

标签: ios core-data restkit dealloc nserror

试图找到我在生产版本中看到的问题的底部,并且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

1 个答案:

答案 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;]

来判断事情是好的。