EXC_BAD_ACCESS NSArray of ManagedObjects(核心数据)
我的 iPhone 应用程序出现了一些奇怪的情况。我正在使用 Core Data 将数据存储在 SQLite 数据库中。我的应用程序启动后第一次尝试读取一个表以返回所有行,以用用户可以从中选择的内容列表填充 UITableView。如果他们选择列表中的顶部项目,我会收到 EXC_BAD_ACCESS 异常。如果他们选择任何其他项目,一切似乎都可以。以下是代码示例:Sport 和 Team 是 NSManagedObjects。 sports 是使用 NSFetchedResultsController (fetchedObjects) 获取的 Sport 对象的 NSArray。我可以在 UITableView 中很好地显示对象列表(我对 cellForRowAtIndexPath() 调用使用相同的数组,没有任何问题
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
Sport *sport = (Sport *)[sports objectAtIndex:indexPath.row];
if (teamSetup) {
if (team.sport != sport) {
[team setSport:sport]; <-- this is where the EXC_BAD_ACCESS happens
NSError *error;
[team.managedObjectContext save:&error];
}
[self.navigationController popViewControllerAnimated:YES];
} else {
// .. do some other stuff
}
[tableView deselectRowAtIndexPath:indexPath animated:YES];
}
更新:它似乎只影响 NSArray 中的最后一条记录,而不是第一个记录,直到它抛出 EXC_BAD_ACCESS 错误。再次重新启动应用程序后,问题消失并且代码按预期工作:(
Something strange is going on with my iphone app. I am using Core Data to store data in a SQLite database. The first time after my app starts up I try to read a table to return all of the rows to fill a UITableView with a list of things for the user to select from. If they chose the top item in the list I get a EXC_BAD_ACCESS exception. If they choose any other item everything seems OK. Here is the code sample: Sport and Team are NSManagedObjects. sports is an NSArray of Sport objects fetched using an NSFetchedResultsController (fetchedObjects). I can display the list of objects fine in the UITableView (I use the same array for the cellForRowAtIndexPath() call without any problem
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
Sport *sport = (Sport *)[sports objectAtIndex:indexPath.row];
if (teamSetup) {
if (team.sport != sport) {
[team setSport:sport]; <-- this is where the EXC_BAD_ACCESS happens
NSError *error;
[team.managedObjectContext save:&error];
}
[self.navigationController popViewControllerAnimated:YES];
} else {
// .. do some other stuff
}
[tableView deselectRowAtIndexPath:indexPath animated:YES];
}
UPDATE: It seems to only affect the last record in the NSArray instead of the first until it throws the EXC_BAD_ACCESS error. After I restart the app again the problem goes away and the code works as expected :(
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
上面发生
EXC_BAD_ACCESS
的行没有任何问题。但是,它可以提供线索,表明团队
或运动
对象存在问题。第一个途径是,其中一个对象已被释放,因为它没有得到充分保留。释放的对象可能不会立即释放。这就是为什么
EXC_BAD_ACCESS
会在奇怪的时间发生。仅当不再需要对象所使用的内存块时,才会释放对象。其他对象当然会使用相同的块。因此,当该块有资格释放时,开发人员就无法控制了。这是由运行时处理的。最好的办法是首先运行分析器,然后运行仪器,使用泄漏仪器进行分析。
Lou Franco 的网站上对这一切都有很好的解释,并提供了有关追踪
EXC_BAD_ACCESS
错误的逐点建议:了解 EXC_BAD_ACCESS
There's nothing wrong with the line above where
EXC_BAD_ACCESS
occurs. However, it could offer a clue that there's an issue with either theteam
orsport
objects. The first avenue to pursue is that one of those objects has been deallocated because it has not been retained sufficiently.Objects that are released may not be deallocated immediately. That's why the
EXC_BAD_ACCESS
can occur at weird times. The objects are only deallocated when the chunk of memory that they were using is no longer needed. Other objects would of course use the same chunk. So when that chunk becomes eligible for deallocation is out of your control as the developer. That's handled by the runtime.Best thing is to first run the Analyzer, then run Instruments, profiling with the Leaks instrument.
There's a great explanation of all this, and point by point advice on tracking down
EXC_BAD_ACCESS
errors on Lou Franco's site:Understanding EXC_BAD_ACCESS