ansaurus

Question

NSManagedObjects that I own being released by main.m?

Answer 1

+1 A:

Rerun your program with the environment variableNSZombieEnabled set to YES. That will tell you when you're double releasing the object, and what object it is. Alternatively, you can debug this in Instruments using the Zombies tool.

Dave DeLong 2010-03-03 22:49:29

Howdy Dave, thanks for the response. As per your request I added the NSZombieEnabled output I got. I didn't see anything helpful there, but hopefully you (or another) will see something!

robenk 2010-03-03 22:59:20

Answer 2

+1 A:

self.tips hasn't been released; the Tip returned by [self.tips objectForKey:categoryNameString] has. It's returning a fault, not an object. Core Data will automatically fault objects when necessary.

Try putting this in when defining your NSFetchRequest:

[fetchRequest setReturnsObjectsAsFaults:NO];

This is what is going on: http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdFaultingUniquing.html, if you want to learn more about it.

Don 2010-03-03 23:10:27

Awesome thanks a lot, going to look at that now. Although even if the "setReturnsObjectsAsFaults" flag fixes it, I am still wondering if I am misusing Core Data somehow (or just doing something non-standard). I've Googled these issue up, down and sideways, and there 's almost nothing out there. That seems odd for an issue where data which was once reliable becomes unreliable at a seemingly random time (also, in a way that is unintuitive with the standard cocoa memory management rules). Doing a fetch and then putting the data into a data structure doesn't seem rare...

robenk 2010-03-03 23:23:38

Oy, unfortunately "setReturnsObjectsAsFaults:NO" doesn't seem to have fixed it. It still crashes in the same way, and the over released tip still says "data: <fault>". I put code like this to try and confirm the flag is working: [fetchRequest setReturnsObjectsAsFaults:NO];NSLog(@"RootView returnsFaults? %d", [fetchRequest returnsObjectsAsFaults]); That printed "RootView returnsFaults? 0", as it should. So shrug.

robenk 2010-03-04 00:03:12

I realized afterward that setReturnsObjectsAsFaults: probably isn't what you want; that will retrieve the related objects instead of faults before they are accessed. It's the Tip itself that is being returned to a fault, probably due to memory constraints. Actually, I was going to ask why you are storing the results of the fetch. With Core Data, it seems like you should be using an NSPredicate to retrieve the data where you are using the NSDictionary

Don 2010-03-04 03:51:01

I think you are onto the root of the problem, the idea of the tip faulting due to memory constraints sounds accurate to me. Re your question about why storing results of the fetch: what I am doing now is (this is a simplification) one fetch request when the app launches and then putting the results of the request into the NSDictionary, which I then pass around to the other views. Correct me if I am wrong, but I think what you are saying is that what I should be doing is have one fetch request _per view_ that fetches just the objects that I need for that specific view (via an NSPredicate)?

robenk 2010-03-04 05:09:31

If you know of a sample code application that has the arrangement you are talking about that would be helpful. All the examples I've looked at seem to have one fetch request at the beginning that is then used the populate one table view. Of course these are also shallow applications. The NSDictionary was answer to "well what if I have more table views than that and each needs different data?"

robenk 2010-03-04 05:21:28

"I think what you are saying is that what I should be doing is have one fetch request per view that fetches just the objects that I need for that specific view" Yes, that's it exactly. You would pass the NSManagedObjectContext to the view when you push the view controller. Then, the view controller would use its own NSFetchRequest to populate the table. So, the examples you see are correct, but the answer to your question, "what if each table needs different data" is that each table uses a separate fetch. It's really cool how easy it all works.

Don 2010-03-04 15:50:50

Some of Apple's example code has the NSManagedObjectContext and NSManagedObjectModel for the whole app in the AppDelegate, like a Singleton, but you could also pass them to the view controllers that need them.

Don 2010-03-04 15:53:44

Awesome, thanks a lot for your help Don. I am going to give this a shot. It will take awhile before I'll know definitively whether it solved the issue (some stuff to rewrite, and I have some other projects that need attention) -- so for the sake of this question I am going to assume it'll work and select this as the answer.

robenk 2010-03-04 16:24:14

I rewrote the app to use the Core Data implementation described in this comment thread and that fixed the problem. Thanks a lot for your help! The comments not needing to use the NSDictionary and having one fetch per view were very helpful.

robenk 2010-03-06 14:57:16

ansaurus

tags:

views:

answers:

NSManagedObjects that I own being released by main.m?

related questions