核心数据：解决奇怪的EXC_BAD_ACCESS错误

如何解决核心数据：解决奇怪的EXC_BAD_ACCESS错误

|| 我面临核心数据一个非常奇怪的问题。让我们对其进行描述：定义假设我有两个模型，分别是ModelA和ModelB。在数据模型中，“ 0”将“ 1”作为一对多关联进行引用，因此，“ 1”与“ 0”具有一对一关联。更新资料当应用程序启动时（尤其是在第一次启动时），或者当用户询问时，我必须为每个“ 0”实例创建或更新所有“ 1”实例。预定“ 0”个实例。对于每个“ 0”实例，我大约有200个“ 1”实例。我使用这样的代码：

ModelB *model = [NSEntityDescription insertNewObjectForEntityForName:@\"ModelB\"
                                              inManagedObjectContext:context];
model.value = [NSNumber numberWithDouble:myValue];
model.modelA = modelA; // I pass modelA as a parameter to the function
[modelA addModelBObject:model];

我不会立即持久存储数据（因为我有很多数据要保存），但是我会在过程结束时这样做。错误有时，并且仅在有时，我在此行出现EXC_BAD_ACCESS错误：

model.value = [NSNumber numberWithDouble:myValue];

启用僵尸，我只能看到那个愚蠢的EXC_BAD_ACCESS，没有更多信息。真正奇怪的错误我试图以不同的方式设置该值，但没有任何改变。然后，我尝试将ѭ16retain，但是什么都没有改变。然后，最后，我尝试将模型一次创建后retain，然后得到通常的EXC_BAD_ACCESS，但是对应于模型的创建，也就是说：

ModelB *model = [[NSEntityDescription insertNewObjectForEntityForName:@\"ModelB\"
                                               inManagedObjectContext:context] retain];

有想法吗？您对如何解决此问题有任何想法吗？难道我做错了什么？顺便说一句，如果我放慢速度（例如，每次创建新模型时都保存上下文），显然不会发生此问题，但这确实减慢了整个应用程序的速度。编辑在极少数情况下，我会得到以下堆栈跟踪：

Serious application error.  Exception was caught during Core Data change processing.  This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification.  -[__NSCFSet addObject:]: attempt to insert nil with userInfo (null)
2011-06-15 11:36:59.864 myApp[457:607] *** Terminating app due to uncaught exception \'NSInvalidArgumentException\',reason: \'-[__NSCFSet addObject:]: attempt to insert nil\'
*** Call stack at first throw:
(
0   CoreFoundation                      0x313dc64f __exceptionPreprocess + 114
1   libobjc.A.dylib                     0x34b3dc5d objc_exception_throw + 24
2   CoreFoundation                      0x313dc491 +[NSException raise:format:arguments:] + 68
3   CoreFoundation                      0x313dc4cb +[NSException raise:format:] + 34
4   CoreFoundation                      0x31351089 -[__NSCFSet addObject:] + 152
5   CoreData                            0x35136dd9 -[NSManagedObjectContext(_NSInternalChangeProcessing) _processPendingUpdates:] + 524
6   CoreData                            0x350f4b3d -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 724
7   CoreData                            0x351363a5 -[NSManagedObjectContext processPendingChanges] + 16
8   CoreData                            0x350d027f _performRunLoopAction + 126
9   CoreFoundation                      0x313b3a35 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 16
10  CoreFoundation                      0x313b5465 __CFRunLoopDoObservers + 412
11  CoreFoundation                      0x313b675b __CFRunLoopRun + 854
12  CoreFoundation                      0x31346ec3 CFRunLoopRunSpecific + 230
13  CoreFoundation                      0x31346dcb CFRunLoopRunInMode + 58
14  GraphicsServices                    0x3658841f GSEventRunModal + 114
15  GraphicsServices                    0x365884cb GSEventRun + 62
16  UIKit                               0x368ded69 -[UIApplication _run] + 404
17  UIKit                               0x368dc807 UIApplicationMain + 670
18  myApp                               0x000028cf main + 82
19  myApp                               0x00002878 start + 40
)
terminate called after throwing an instance of \'NSException\'

编辑2 这是异常的堆栈跟踪：

#0  0x313f1460 in __CFBasicHashAddValue ()
#1  0x3133fff8 in CFBasicHashAddValue ()
#2  0x31344162 in CFSetAddValue ()
#3  0x31351012 in -[__NSCFSet addObject:] ()
#4  0x3514211a in _PFFastMOCObjectWillChange ()
#5  0x3512ed46 in _PF_ManagedObject_WillChangeValueForKeyIndex ()
#6  0x35132e7e in _sharedIMPL_setvfk_core ()
#7  0x3513316a in _svfk_2 ()
#8  0x0003b750 in -[_TassoStorico setValoreValue:] (self=0x6d97bf0,_cmd=0x49064,value_=1.02600002) at _TassoStorico.m:87
#9  0x0001b62e in -[EuriborParser(hidden) readStoricoForzato] (self=0x74200d0,_cmd=0x48ff7) at EuriborParser.m:236
#10 0x31349f02 in -[NSObject(NSObject) performSelector:withObject:] ()
#11 0x000441c4 in -[MBProgressHUD launchExecution] (self=0x90a6ff0,_cmd=0x4b83f) at MBProgressHUD.m:482
#12 0x352b3388 in -[NSThread main] ()
#13 0x353255cc in __NSThread__main__ ()
#14 0x34e20310 in _pthread_start ()
#15 0x34e21bbc in thread_start ()

解决方法

CoreData不是线程安全的；看来这是您的问题，请尝试查看此问题 , 我遇到了类似的问题（[managedContext save]上的EA_BAD_ACCESS），该问题是由KeyValueObserver引起的，应该在应删除时将其删除。很难追踪。这意味着即使使用ARC，我也遇到这种情况。 , 持久存储迁移后重置受管对象上下文我有类似的问题。我还使用几个线程，并且使用Core Data的migratePersistentStore:toURL:options:withType:error:函数。就我而言，该错误是在另一个线程中迁移之后立即发生的。我以为我的问题与线程有关，所以我开始在代码中加倍考虑线程安全性，但实际上，在对托管对象上下文中的对象进行任何后续操作之前，一次调用ѭ23即可解决所有问题。核心数据行为奇怪的是，“ 24”总是给我回引用一个不存在的对象，因此我正在访问不存在的对象并接收“ 12”。重置上下文后，该函数将显示正确的行为。 , 这两行是多余的，并且可能很危险：

model.modelA = modelA; // I pass modelA as a parameter to the function
[modelA addModelBObject:model];

受管对象上下文将自动为您发送对等关系，因此无需手动进行。实际上，我认为这可能会导致危险的循环。您可以只使用一条线，也可以使用另一条线，并且关系的两侧都将自动设置。我建议：

model.modelA = modelA;

...因为它更简单。

核心数据：解决奇怪的EXC_BAD_ACCESS错误

如何解决核心数据：解决奇怪的EXC_BAD_ACCESS错误

解决方法

相关推荐