ansaurus

Question

Core Data Crashing during NSManagedObjectContext processPendingChanges

Answer 1

+1 A:

It looks like one of the items in one of your database arrays is getting released one too many times (and therefore gets deallocated). It's crashing trying to sort your array, making a comparison with a deallocated object.

Try running your program with NSZombieEnabled -- it prevents the deallocation so you can see which object is getting messages sent to it with a retain count of 0.

Matt B. 2010-02-03 04:21:32

Matt thanks for the thoughts. Your explanation of what is happening makes sense (theoretically). I have tried running with NSZombieEnabled many times but with no luck...

kdbdallas 2010-02-03 04:30:05

Aha! The bad access is at `0x0b`. I bet you're storing a number (the value 11) as a primitive `int` instead of an `NSNumber`. That would also explain the error on the comparison. Go back through your source and ensure that you're giving all your Core Data entities NSNumbers, not ints.

Matt B. 2010-02-03 06:46:47

Matt, wouldn't using a int cause a conversion from int to pointer warning? My entire code is warning free and clean to Clang Static Analyzer. I will still double check, but thought I would ask. Thanks for you help so far!

kdbdallas 2010-02-03 06:56:46

If you're using KVC to set the number (as you probably would with Core Data), there's no compile-time checking.

Matt B. 2010-02-03 17:14:56

Hey Matt. I did some searching and didn't find anywhere with a int/NSInteger instead of a NSNumber, so I thought I would give running with zombies again, and this time I got a hit and with the EXACT same stack trace. The zombie reported: *** -[CFDate class]: message sent to deallocated instance 0x9d87480.So if this is a date stored in Core Data why would it be getting over deallocated and causing a crash?

kdbdallas 2010-02-04 04:22:50

I ended up thinking I would take a break from this issue for a bit and just take some time killing any leaks. Well in the process of fixes a couple of leaks this stopped happening! So it seems that it was the miss-memory-management of some objects that were pointers to data managed by core data. Thank you for your help!

kdbdallas 2010-02-09 21:43:12

Glad to hear! I try to regularly run my program through the Leaks instrument. It really does tend to help save you headaches like this, and it makes chasing down the leaks easier (since you only need to check new code).

Matt B. 2010-02-09 23:55:38

Answer 2

A:

If you are using a NSFetchedResultsController then there may be an error in that code and it is not easy to see that. I would suggest putting in some log statements into your NSFetchedResultsController delegate methods and watch which one is getting fired.

Since the NSFRC is fired as part of the save routine of the NSManagedObjectContext, an error in its delegate can easily be misinterpreted as an error in the save itself.

Update 1

If its on a date then perhaps when you set that date somewhere you are overreleasing it yourself? Perhaps calling a -release on a [NSDate date]. That type of error would be hidden until Core Data tried to access the date object.

Marcus S. Zarra 2010-02-04 19:56:12

Marcus, thank you for your insights. I checked and I am not using NSFetchedResultsControllerDelegate anywhere. All but 1 of my NSFetchedResultsControllers doesn't set the delegate, and the one that does, does NOT implement any of the delegate protocols methods.When I run with Zombies I get: * -[CFDate class]: message sent to deallocated instance 0x9d87480.So if this is a date stored in Core Data why would it be getting over deallocated and causing a crash?

kdbdallas 2010-02-05 04:38:07

ansaurus

tags:

views:

answers:

Core Data Crashing during NSManagedObjectContext processPendingChanges

Update 1

related questions