核心数据在删除后试图保存时崩溃
我遇到了核心数据中的上下文无法保存的问题。核心数据在删除后试图保存时崩溃
当我尝试调用[context save:]时,发生随机崩溃。有时它可以工作,有时它不会崩溃应用程序。这是我的删除代码。我已经能够通过检查[contextrespondsToSelector]保存来减少崩溃的次数。奇怪的是,即使它失败(respondsToSelector失败),我没有调用保存,它仍然被删除!?但是,当respondsToSelector成功时,我试图调用save,它仍然有时会崩溃。所以这段代码在测试中更稳定一些,但我认为Core Data和save方法有问题。追查问题非常困难,因为它确实看起来是随机的。
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
if (editingStyle == UITableViewCellEditingStyleDelete) {
// Delete the managed object.
NSManagedObjectContext *context = [self.fetchedResultsController managedObjectContext];
Accidents* accidentDelete = [self.fetchedResultsController objectAtIndexPath:indexPath];
[context deleteObject:accidentDelete];
// Causing crash...
NSError *error = nil;
if ([context respondsToSelector:@selector(save:)])
if (![context save:&error]) {
// Update to handle the error appropriately.
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
exit(-1); // Fail
}
else
NSLog(@"Error! Context does not respond to save!");
}
}
我假设崩溃意味着--EXC_BAD_ACCESS。如果不是,请张贴您得到的异常和堆栈跟踪。
发生EXC_BAD_ACCESS是因为您正在访问错误的内存。通常这是因为你正在访问释放的内存。最简单的方法是打开僵尸 - 这会让所有的deallocs什么都不做,但是当你访问一个已经调用了dealloc的对象时,它会在控制台中抱怨,你访问的确切点一个释放的对象。
我解释了很多关于EXC_BAD_ACCESS在这里,有一些故障排除说明(和指令开启僵尸)
http://www.loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
转到项目 - >编辑活动的可执行,转到参数选项卡而在环境变量部分,添加
NSAutoreleaseFreedObjectCheckEnabled NSZombieEnabled NSDebugEnabled
而且每个设置为YES。你可以不选中它们,但是如果你检查它们,那么你的应用程序现在会对autorelease和release做一些额外的检查,并且当你做错了的时候给你一个很好的堆栈跟踪。一个常见的问题是,当对象已经被设置为autorelease时,你认为你需要调用release(请参阅昨天的规则是什么)。
我没有得到一个不好的访问,而是一个SIG-BIT。但是,添加环境变量的提示是我需要弄清楚它为什么会崩溃的原因。出于某种原因,我过早发布了一个日期对象,然后访问它。当核心数据去保存它时,它不再存在并且崩溃。我通过将日期对象设置为自动释放对象[NSDate日期]来解决此问题。它现在似乎工作。启用environ变量后,我收到一条控制台消息,说我正在向发布的日期对象发送消息,这是我需要的提示。 – 2010-10-05 07:24:33