saveWithBlock (iOS 7) and saveWithBlockAndWait (iOS8) methods freeze the whole application

[false]

Hi,

I am having important freezes issues using the saveWithBlockAndWait on iOS 8 and saveWithBlock on iOS 7.

The applications does not crash, it freezes. You MUST kill it to use it again.

I have tested on 2.3 pre-beta 3 and the develop branch.

Exemple :

[MagicalRecord saveWithBlock:^(NSManagedObjectContext *localContext) {
     Book* localBook = [aBook MR_inContext:localContext];
     localBook.downloadState = @(kBookDownloadInProgress);
     localBook.progress = @0;
}];

[Alydyn]

What happens if instead of using MR_inContext: you create an NSMangedObjectID variable from aBook and then use Book localBook = [localContext existingObjectWithID:error:]?

[waltermvp]

I experience the same issue in iOS 7. The completion block never gets called. Ive temporarily fixed it by using savewithblockandWait

[suculent]

Do you use saving stack? I had the same issue wheb reading/writing with any other stack, even with v3.

Odesláno z iPhonu

1. 9. 2014 v 20:47, Walter Martin Vargas-Pena notifications@github.com:

I experience the same issue in iOS 7. The completion block never gets called. Ive temporarily fixed it by using savewithblockandWait

— Reply to this email directly or view it on GitHub.

[waltermvp]

@suculent saving stack?

[false]

I tested

Book* localBook = (Book*)[localContext existingObjectWithID:aBook.objectID error:&error];

There is no error, and the application still freezes on iOS 7.

[vu0tran]

+1

[tonyarnold]

Would you guys mind confirming that this issue still occurs with 2.3 beta 5? I had inadvertently broken some of the logic around which thread saving occurred on around beta 3.

[false]

I checked, using the 2.3 beta5 tag : iOS 7 : It seems saveWithBlock does not freeze the application anymore iOS 8 : The application still freezes "randomly" when using saveWithBlockAndWait. It does not freeze at all when using saveWithBlock .

[Alydyn]

"randomly" sounds like a concurrency issue in your code.

[tonyarnold]

@false thanks — that's certainly not the expected behaviour. Any chance you could provide a small sample project that demonstrates the problem? I'm happy to dig into it, but I need a reliable reproduction of the issue you're seeing.

[somerobots]

Dear Tony,

I have had this same problem with an iOS 9 app. During the development of the first (and present) release of the App I used Magical Record to rapidly build the app with. However, the app often freezes with a deadlock on NSFetchedResultsController performFetch(). I'm not sure what I was doing wrong, everything was standard with saveWithBlock and saveWithBlockAndWait. I audited the entire app for thread violations.

In the end I had to reconsider using Magical Record as the basis for my Core Data wrapper. Thank you kindly for this excellent library, but I think maybe there are some Apple bugs with the Confinement approach to Core Data stack? I'm not sure.

I consulted a book on Core Data (https://www.objc.io/books/core-data/) and this gave me some insight how to build a Core Data stack. I used a Main Queue context for all UI code to retrieve data from. This context had its own Persistent Store Coordinator. Then, a second Private Queue context to save data into. This again had its own Persistent Store Coordinator. When the private queue is saved, the main queue context observes the change notification and does an in memory merge of the data. I have found this stack to be performant and importantly no deadlock.

I was very very very suspicious of touching performBlockAndWait, I have a suspicion there's issues using this. In the end it was entirely possible to build the app using very minimal uses of that method. performBlock seems much safer.

I have found there's a real lack of quality information about Core Data, but this book helped explain it for me, and it seems much of the pain points of Core Data are now fixed with the new additions it has.