核心數據在刪除後試圖保存時崩潰

我遇到了核心數據中的上下文無法保存的問題。核心數據在刪除後試圖保存時崩潰

當我嘗試調用[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!"); 
    } 
}

來源

2010-10-02 Leon Fu

我假設崩潰意味着--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（請參閱昨天的規則是什麼）。

來源

2010-10-02 17:03:21

我沒有得到一個不好的訪問，而是一個SIG-BIT。但是，添加環境變量的提示是我需要弄清楚它爲什麼會崩潰的原因。出於某種原因，我過早發佈了一個日期對象，然後訪問它。當核心數據去保存它時，它不再存在並且崩潰。我通過將日期對象設置爲自動釋放對象[NSDate日期]來解決此問題。它現在似乎工作。啓用environ變量後，我收到一條控制檯消息，說我正在向發佈的日期對象發送消息，這是我需要的提示。 – 2010-10-05 07:24:33

核心數據在刪除後試圖保存時崩潰

回答

相關問題