I am still searching for a way to solve my memory leaks. For the moment I have a leak at this line of code.
return [UIImage imageWithContentsOfFile:path];
Anybody an idea?
Thx in advance!
- (UIImage *)imageAtIndex:(NSUInteger)index {
// use "imageWithContentsOfFile:" instead of "imageNamed:" here to avoid caching our images
NSString *imageName = [self imageNameAtIndex:index];
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *path = [[paths objectAtIndex:0] stringByAppendingPathComponent:imageName];
//NSString *path = [[NSBundle mainBundle] pathForResource:imageName ofType:#"jpg"];
return [UIImage imageWithContentsOfFile:path];
}
- (void)configurePage:(ImageScrollView *)page forIndex:(NSUInteger)index
{
page.index = index;
page.frame = [self frameForPageAtIndex:index];
// To use full images instead of tiled images, replace the "displayTiledImageNamed:" call
// above by the following line:
// [page displayImage:[self imageAtIndex:index]];
[page displayImage:[self imageAtIndex:index]];
}
When leaks identifies a line of code as being a leak, it is not claiming that said line of code is the actual leak. Only that said line of code is the source of the allocation that was leaked.
Thus, the image returned by imageWithContentsOfFile: is being over-retained somewhere else and it is your job to find out where.
Which is generally pretty easy; turn on the "retain tracking" [IIRC] checkbox on the little configuration panel of the Allocations instrument, run your app, and then click through one of the leaked UIImages to see a list of exactly where the image was retained and released. One of those retains will not be balanced and that is your leak.
Though slightly orthogonal, I describe how to do this in a post about using Heapshot Analyais to find leaks.
Related
I'm working on an OSX application where I need to store 446 CGLayers that get placed in a PDF context and am wondering if there's a way to write and read them from a file, rather than generating them when the application loads
I've read that CGLayer is no longer recommended, but I feel they really fit what I need. Also, if I use bitmapGraphicsContexts, they can pixelate when zooming in.
I am able to store them in NSArrays, both by storing them in NSValue and puting them into the array by bridging. I've also tried storing them in C arrays, but that didn't work out.
My problem comes when trying to store these arrays in a file. writeToFile: doesn't work with CGLayers, but NSKeyedArchiver/NSKeyedUnarchiver hasn't worked either, both when the layers are in NSValues or bridged.
Here's my method that attempts to write and read an array containing a single layer from a file.
+(CGLayerRef) colorAnnotations:(CGContextRef)context{
float symbolSize = 8;
CGRect glyphBox = CGRectMake(0,0, 8, 8);
CGLayerRef annotationLayer = CGLayerCreateWithContext (context,glyphBox.size, NULL);
CGContextRef annotaionLayerContext = CGLayerGetContext(annotationLayer);
CGMutablePathRef annot = CGPathCreateMutable();
//Drawing annotation
/*...*/
NSMutableArray *test = [[NSMutableArray alloc]init];
[test addObject:[[NSValue alloc] initWithBytes:&annotationLayer objCType:#encode(CGLayerRef)]];
//Getting file path in Documents directory
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *dataPath = [documentsDirectory stringByAppendingPathComponent:#"/annots.data"];
[NSKeyedArchiver archiveRootObject:test toFile:dataPath];
NSMutableArray *testLoads = [NSKeyedUnarchiver unarchiveObjectWithFile:dataPath];
CGLayerRef layerToReturn;
[[testLoads objectAtIndex:0]getValue:&layerToReturn];
return layerToReturn;
}
I get [NSKeyedArchiver encodeValueOfObjCType:at:]: unknown type encoding ('^')') was raisedfrom this, pretty sure because of the CGLayerRef type.
The lines needed to draw the different annotations I need are pretty long, so I've been trying to figure out a way to have them made and stored in a file without having to make them on startup each time. So far I'm not seeing a way to do this, but was hoping someone here may know of one and would appreciate any help.
I would need some help solving this memory leak problem. I am using ARC.
The potential leak is on this line:
NSURL *aFileURL = [NSURL fileURLWithPath:filePath isDirectory:NO];
Here is the code:
// === Check if the game should play sound === //
if (sound == YES) {
//==== PLAY THE LOOSING SOUND ====//
// Form a URL to the sound file, which in init using the Path
NSBundle *mainBundle = [NSBundle mainBundle];
NSString *filePath = [mainBundle pathForResource:#"wrong2" ofType:#"wav"];
NSURL *aFileURL = [NSURL fileURLWithPath:filePath isDirectory:NO];
// Create a sound ID,
SystemSoundID myID;
// Register the sound
AudioServicesCreateSystemSoundID((__bridge_retained CFURLRef)aFileURL, &myID) ;
// Play the sound!
AudioServicesPlaySystemSound(myID);
}
Replace __bridge_retained by __bridge.
__bridge_retained would mean that you transfer the ownership of aFileURL to AudioServicesCreateSystemSoundID() and that function would have to release it (which it doesn't).
And I think you should also call
AudioServicesDisposeSystemSoundID(myID)
when the sound object is no longer needed.
Tip: When the static analyzer shows the "Potential leak" warning, click on the blue icon to the left of the warning and you will see detailed information about the problem.
I have a memory leak which crashes my App while copying / creating images width NSFileManager.
When i profile my App with "Allocations", everything looks fine. The Allocated Memory Goes up from aprox 1.5 MB to 6 MB during every recoursion and then drops to 1.5MB again.
But the "Real Memory" and "Virtuel Memory" grows to aprox 150MB and then the App crashes.
I receive Memory Warnings Level 1 and 2 before.
here is the function us use:
-(void) processCacheItems:(NSMutableArray*) originalFiles
{
if ( [originalFiles count] == 0 )
{
[originalFiles release];
return;
}
else
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *curFileName = [originalFiles lastObject];
NSString *filePath = [documentsDirectoryPath stringByAppendingPathComponent:curFileName];
NSURL *fileURL = [NSURL fileURLWithPath:filePath];
CGSize destinationSize = CGSizeMake(150,150);
CGSize previewDestinationSize = CGSizeMake(1440.0, 1440.0);
UIImage *originalImage = [UIImage imageWithContentsOfFile:filePath]; // AUTORELEASED
// create thumb and copy to presentationfiles directory
UIImage *thumb = [originalImage resizedImageWithContentMode:UIViewContentModeScaleAspectFit
bounds:destinationSize
interpolationQuality:kCGInterpolationHigh]; // AUTORELEASED
// the resizedImageWithContentMode: does not semm to make the problem, because when i skip this and just use the original file the same problem occours
NSString *thumbPath = [thumbsDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager createFileAtPath:thumbPath contents:UIImageJPEGRepresentation(thumb, 0.9) attributes:NULL];
// create thumb and copy to presentationfiles directory
UIImage *previewImage = [originalImage resizedImageWithContentMode:UIViewContentModeScaleAspectFit
bounds:previewDestinationSize
interpolationQuality:kCGInterpolationHigh]; // AUTORELEASED
NSString *previewImagePath = [previewsDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager createFileAtPath:previewImagePath contents:UIImageJPEGRepresentation(previewImage, 0.9) attributes:NULL];
// copy copy original to presentationfiles directory
NSString *originalPath = [originalFilesDirectoryPath stringByAppendingPathComponent:curFileName];
[fileManager copyItemAtPath:filePath toPath:originalPath error:NULL];
[originalFiles removeLastObject];
[pool drain];
[self processCacheItems:originalFiles]; // recursion
}
}
Thank you for your Hint.
I fond out, that the Problem was not a leak, but the memory Allocation was too big when scaling down Big Images in "resizedImageWithContentMode:" That made the App crash.
I changed the Image scaling to use the Image I/O framework.
Now it works fine.
UPDATE: This answer is outdated. If you are using ARC, ignore it .
How do you allocate NSFileManager?
I have experienced that allocating it via the + defaultManager method, which is deprecated, produces memory leaks (or Instruments says so, Instruments sometimes reports memory leaks where there are not).
Generally, you should allocate it with [[NSFileManager alloc] init] and release when you no longer need it.
I'm trying to save an NSMutableArray called queueArray so it can be loaded again after the app has been quit. I used a few tutorials to get me going and this is the code I have come up with. The problem seems to be that "initWithCoder" and "encodeWithCoder" are not being called, shown by no NSLog calls and no stopping at breakpoints. I have added the NSCoding protocol to the .h file and I know that queueArray is not nil and it contains MPMediaItems. Here is some of the code I use to try to save and load the array:
-(IBAction)saveQueuePressed {
NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSString *filePath = [rootPath stringByAppendingPathComponent:#"queueArray.archive"];
//should cause encodeWithCoder to be called
[NSKeyedArchiver archiveRootObject:queueArray toFile:filePath];
}
-(IBAction)loadQueuePressed {
NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSString *filePath = [rootPath stringByAppendingPathComponent:#"queueArray.archive"];
//should cause initWithCoder to be called
queueArray = [NSKeyedUnarchiver unarchiveObjectWithFile:filePath];
}
-(void)encodeWithCoder:(NSCoder *)coder {
NSLog(#"encodeWithCoder");
[coder encodeObject:queueArray forKey:#"savedQueueArray"];
}
-(id)initWithCoder:(NSCoder *)decoder {
NSLog(#"initWithCoder");
queueArray = [decoder decodeObjectForKey:#"savedQueueArray"];
return self;
}
Any help will be greatly appreciated!
The encodeWithCoder: and initWithCoder methods are called when you archive/unarchive an object that responds to them. From what I understand, you have those methods in your class, but the object you are actually archiving (queueArray) is not an instance of that class, it's an NSMutableArray.
If you do want to save your entire object, you can change your saveQueue method to this
-(IBAction)saveQueuePressed {
NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSString *filePath = [rootPath stringByAppendingPathComponent:#"queueArray.archive"];
// saving the array shouldn't, but saving the self object
//should cause encodeWithCoder to be called:
[NSKeyedArchiver archiveRootObject:self toFile:filePath];
}
But if you just want to save the array, I guess you can just use saveQueuePressed and loadQueuePressed, I don't think you need the encode/init WithCoder: methods
Update:
Maybe your path is not right.
Try
NSString *rootPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSString *filePath = [[rootPath stringByAppendingPathComponent:#"queueArray.archive"] stringByExpandingTildeInPath]];
Filipe is right! Your comment said you still didn't use his method.
I had this issue too. Switching from the dictionary's atomic write method to the keyedArchiver fixed it, luckily I only had to change one thing, the line that said writeToFile: is now the archive function.
Now my program's working. For some reason, even when responding to NSCoding, the custom object is not being encoded and breaks my dictionary. Is this a bug with iOS? I've read a fair number of Apple Manuals, but I've also seen a fair number of typos and missing info (For example, try MKMapRect functions without the videos to explain them), or Core Animations referencing the Run Loop before you learn threading, I could go on, half finished sentences in Quartz... so yeah, I've read the manuals and this perplexes me, we have to get a more open iOS SDK at some point, hopefully
I have an About View which I push onto a NavigationController. The view has one UILabel which is connected to an IBOutlet. In viewDidLoad I populate the UILabel with the bundle version number (a string). Testing with instruments suggested that the line marked with a comment is leaking memory: -
viewDidLoad {
[super viewDidLoad];
self.title = #"About";
// Line below is the suggested culprit ***
NSString *versionLabel = [[NSString alloc] initWithFormat:#"Version %#",
[[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString *)kCFBundleVersionKey]];
self.applicationVersion.text = versionLabel;
[versionLabel release];
versionLabel = nil;
}
I'm assuming it is suggesting the NSString and not anything else on the line ...
My questions is Why ?
My suspicion is that you're leaking the applicationVersion UILabel. That will cause the string to leak as a by-product. The most common reason for this on iPhone is failure to follow the NIB memory management rules.
It may actually be the mainBundle or infoDictionary that is leaking - it is possible that the system is caching one or other of those and thus they are being created and then never released.
Try adding in to your applicationDidFinishLaunching the code:
[[NSBundle mainBundle] infoDictionary];
Without any other code and see if Leaks points to that line as the location of the leak. In that case, caching is the issue and you can ignore it.
You don't even need to create an instance of NSString in that case, simply use the following method that acts on the NSString class (not an instance):
NSString *versionLabel = [NSString stringWithFormat:#"Version %#",
[[[NSBundle mainBundle] infoDictionary]
objectForKey:(NSString*)kCFBundleVersionKey]];
If you use NSString this way, you do not have to release versionLabel because memory was never allocated.