views:

92

answers:

4

I've narrowed a memory leak problem down to this specific block of code:

NSFetchRequest *req = [NSFetchRequest new]; 
NSEntityDescription *descr = [NSEntityDescription entityForName:@"Capture" inManagedObjectContext:dataContext]; 
[req setEntity:descr]; 
NSSortDescriptor *sort = [[NSSortDescriptor alloc] initWithKey:@"created_at" ascending:NO]; 
[req setSortDescriptors:[NSArray arrayWithObject:sort]]; 
[sort release]; 
NSError *error; 
NSArray *ret = [dataContext executeFetchRequest:req error:&error]; 
[req release]; 

This block exists in either the init or viewDidLoad method for a view controller a layer or two down in the navigation controller.

Where I'm confused and not sure what to do is that I'm getting memory leaks with this code related to CoreGraphics, Foundation, and even JavaScript Core, but I'm unsure how to correct the problem (not sure what the problem is). This only happens when running Instruments on the Device installation, not the Simulator.

[ This won't let me post the photo of Instruments, So here's the photo: http://twitpic.com/27vwm1 ]

By way to background, my Core Data model used to have a property that held a transformed UIImage, but I've since converted that to an NSNumber and rebuilt the object classes for my project. Could that have something to do with it and is there another step I need to take when changing around my model?

Thx

*Update: * changed URL for picture

A: 

If you hit the source button in the bottom panel of Instruments and drag the source file into it, it will show you the line in your code where it think the leak is. If the app is running, you can copy the address of the objects shown to the debugger and like this:

po 0x1a831

... and it will print a description of the object at that address.

Most likely, your leak is resulting from a side effect of fetching your managed objects. Value transformers are a common source of such leaks because they create objects every time they are used. I would look at the managed object subclasses themselves for the source of the leak.

TechZen
Jeof
Heck, I'm not sure. I just checked and the new version that came with Xcode 3.2.3 has a different interface from prior versions and a different one from the Instruments user's guide. It used to be in the bottom of the detail view but those buttons are not there anymore.
TechZen
Here's how it used to work http://stackoverflow.com/questions/1634067/iphone-analyzing-leaks-with-instruments/1639237#1639237
TechZen
A: 

Jeof, did you resolve this?

Priyesh
No. I had to abandon Core Data and went to a different data model.
Jeof
A: 

I'm having similar problem in my app, and a friend too in another app. We've both checked and re-checked our code, and there's nothing wrong in our side (we're doing the same basic things as in apple's sample code).

It seems that there's nasty side effects when using core data on device, that does not happen on the simulator.

I've spent a lot of time on that issue, and I'm at the point the problem is really on the apple framework and not on my code. I think it would be a good idea to submit a bug report for that problem.

Note: I'm having this problem whithout using any custom or transformable objects, only string attributes in my managed objects.

noda
A: 

Agreed, same problem here. Even if you just use the code generated by the wizard with a split view and core data it leaks ! It took me a while to find this out. I'd writtten a ton of code on an application and when ready to start leak testing could not find the source of the leak as instruments pointed nothing out in my code. I had excactly the same symptoms you have. So after a few days of commenting out my code i decided just to fire up the template project for splitview, tick core data and not add any code myself. Guess what ? same damn leak. It only happens at app startup and only if you have used the app to add items. Im surprised this hasnt been fixed by Apple or at least a workaround mentioned. Am i the only one using Core Data with a Splitview ?

Mattyd