initWithContentsOfURL leaks memory within NSOperation subclass. Anyone else seeing this? - iphone

I have been living on Instruments for last few hours staring at a puzzling memory leak. I have isolated it to this single line of code in an NSOperation subclass I wrote:
NSData *myData = [[NSData alloc] initWithContentsOfURL:[NSURL URLWithString:myURLString]];
Periodically this will leak 3500 bytes. Is anyone else seeing this? If so, is there a work around?
Thanks in advance.
UPDATE:
Here is the relevant section of code within the main() body of my NSOperation subclass:
- (void)main {
// ...
NSData *sequenceData =
[[NSData alloc] initWithContentsOfURL:[NSURL URLWithString:concatenatedURLString]];
NSString *sequenceString =
[[NSString alloc] initWithBytes:[sequenceData bytes] length:[sequenceData length] encoding:NSUTF8StringEncoding];
NSDictionary *result = [NSDictionary dictionaryWithObjectsAndKeys:
self.chromosome, #"chromosome",
[NSNumber numberWithInt:self.basepairStart], #"basepairStart",
[NSNumber numberWithInt:self.basepairEnd], #"basepairEnd",
sequenceData, #"sequenceData",
sequenceString, #"sequenceString",
nil];
[sequenceData release];
[sequenceString release];
[self.target performSelectorOnMainThread:self.action withObject:result waitUntilDone:NO];
}
As you can see sequenceData and sequenceString are properly released. Also, I have confirmed that all ivars of this subclass (chromosome. etc.) are properly memory managed.
-Doug

You have to release or autorelease myData, otherwise it will leak according to the Cocoa Memory Management Rules

Related

Memory leak when using NSString inside for loop

I have 100 images in my resource bundle named like image1.jpg,image2.jpg.
Basically what i am trying to do is create path names to those images dynamically inside a for loop.
While testing in simulator,the images loaded fine and the app did not crash.But while testing the app with instruments i was shocked to see the heavy memory leak that was happening while i was creating the path1 object.
I am pasting the entire method here for reference
- (id)init {
self = [super init];
if (self) {
self.arrayImages = [[[NSMutableArray alloc] init] autorelease];
for(int i=1 ; i<100 ; i++){
NSString *str = [NSString stringWithFormat:#"Century%d",i];
NSString *path1 = [[NSBundle mainBundle] pathForResource:str ofType:#"jpg"];
[self.arrayImages addObject:path1];
}
}
return self;
}
As i have not made use of any alloc inside the loop i dont have any ownership and hence no right to release the object.What is the reason for this memory leak??
Kindly explain the problem and provide the necessary solution in order to fix it..
As always,any help is highly appreciated..
arrayImages is retaining path1, and so if you do not release arrayImages it will leak. How are you creating arrayImages, and are you releasing it anywhere?
Edited based on comments:
Make sure you release arrayImages in your -dealloc method like so: [arrayImages release]; (note the lack of self).
There is no leak in the code you've shown.
There are (at least) two possibilities:
You have a leak in code you didn't paste into your question
Everything is fine and Instruments gave you a false-positive
Your loop will create a lot of autoreleased variables. These won't be deallocated until after the loop has finished, but that's how it's supposed to work.
The reason for the leak would be this line right here:
NSString *str = [NSString stringWithFormat:#"Century%d",i];
By using convenience methods in Objective-C, what happens in the background is the following:
NSString *str = [[[NSString alloc] initWithFormat:#"Century%d", i] autorelease];
Not using alloc/init to create a weak reference is a misconception. You are always the owner of a created object, no matter how you create it. The convenience method simply does the alloc/init and autoreleases it for you.
Here's what I would suggest you do to avoid leaking memory:
- (id)init {
self = [super init];
if (self) {
self.arrayImages = [[[NSMutableArray alloc] init] autorelease];
NSAutoreleasePool *tmpPool = [[NSAutoreleasePool alloc] init];
for(int i = 1 ; i < 100 ; i++) {
NSString *str = [NSString stringWithFormat:#"Century%d",i];
NSString *path1 = [[NSString alloc] initWithString:[[NSBundle mainBundle] pathForResource:str ofType:#"jpg"]];
[self.arrayImages addObject:path1];
[path1 release];
}
[tmpPool drain];
}
return self;
}
Let me know if this works better for you.
-EDIT- Allocating the path1 object and releasing it after adding to arrayImages.

Why does this line leak memory?

[row setObject:[NSString stringWithCString:value encoding:NSUTF8StringEncoding] forKey:columnName];
where row is a NSMutableDictionary..is there a different way to inject this string into my dictionary?
Profiling tools says that because the string is "autoreleased", so you could optimize it by
putting a NSAutoreleasePool around it
alloc/init the str then release it
or just ignore the optimization message.
This is one way:
NSString *str = [[NSString alloc] initWithCString:value encoding:NSUTF8StringEncoding];
[row setObject:str forKey:columnName];
[str release];
I have had this problem before, because the NSMutableDictionary owns the object it won't be released until the Dictionary is released.
I would suggest that somewhere in your code an object is being dealloc'd without properly releasing the variables it owns, likely the NSMutableDictionary *row.

MWFeedParser stringByReplacingXmlEntities memory leak

NSURL *xmlUrl = [[NSURL alloc] initWithString:#"http://www.xml-document.xml"];
NSString *converted = [[NSString alloc] initWithContentsOfURL:xmlUrl encoding:NSISOLatin1StringEncoding error:nil];
converted = [converted stringByReplacingOccurrencesOfString:#"&" withString:#"&"];
converted = [converted stringByDecodingXMLEntities];
The last line takes up 98.3% of the memory in Instruments > Leaks.
And it's smashing my Log window with:
__NSAutoreleaseNoPool(): Object 0x6d10ba0 of class UIView autoreleased with no pool in place - just leaking
Why? I think that method has worked good before...
After some more googling I found that it has to be because of these methods:
[self performSelectorInBackground:#selector(load) withObject:loadingIndicator];
[self performSelectorInBackground:#selector(getEvents) withObject:nil];
So I've tried allocating an NSAutoReleasePool and the release it after the work is done in the methods.
Now i receive EXC_BAD_ACCESS message.
This did not happended before I decided to run those methods in the background. So what's the problem here?

NSAutoreleasePool issues on the iPhone

I have a small iPhone app which has a button on the first view. When I select this button I load up my new view which has an image on it. I'm currently using the following code to load the image from an online source on a separate thread, whilst allowing the user to continue controlling the application:
- (void) loadImageTest
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSURL *url = [[NSURL alloc] init];
url = [NSURL URLWithString:logoPath];
NSData *data = [[NSData alloc] init];
data = [NSData dataWithContentsOfURL:url];
loadingImage = [UIImage imageWithData:data];
titleLogoImage.image = loadingImage;
//[pool drain];
[pool release];
}
This is called from this line of code in the new view's init:
[NSThread detachNewThreadSelector:#selector(loadImageTest) toTarget:self withObject:nil];
Now this works fine (ish), but if I close the new view and then load a new one up again in quick succession (or just after-wards in some cases) it will bomb out with the classic EXC_BAD_ACCESS. I'm sure that this is due to the code within the thread pool, but can anyone see why this is happening?
Thanks
Yours:
// This is ok, you might try using NSURLConnections asynchronous methods instead of making
// your own thread.
[NSThread detachNewThreadSelector:#selector(loadImageTest) toTarget:self withObject:nil];
- (void)loadImageTest
{
// This is fine
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// you're making and then abandoning this url object so it will leak
NSURL *url = [[NSURL alloc] init];
// this is fine
url = [NSURL URLWithString:logoPath];
// again making and abandoning an object
NSData *data = [[NSData alloc] init];
data = [NSData dataWithContentsOfURL:url];
// this works, but is not thread safe,
// can't operate on UIKit objects off the
// main thread
loadingImage = [UIImage imageWithData:data];
titleLogoImage.image = loadingImage;
// this is fine
//[pool drain];
[pool release];
}
Cleaned up to make things thread safe, etc. Should help:
// I'm assuming you have a iVar for logoPath but we don't want to
// make threaded calls to an iVar (it's not mutable, so you could do it, but it's just bad form)
// If i'm wrong about logoPath being an iVar don't sweat copying it.
- (void)whateverMethodYouWant
{
NSString *aLogoPath = [[logoPath copy] autorelease];
[NSThread detachNewThreadSelector:#selector(loadImageForPath:) toTarget:self withObject:aLogoPath];
}
- (void)loadImageForPath:(NSString *)aLogoPath
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSData *data = [NSData dataWithContentsOfURL:[NSURL URLWithString:aLogoPath]];
// the performSelector will retain the data until the method can be performed
[self performSelectorOnMainThread:#selector(setImageForTitleLogo:) withObject:imgData waitUntilDone:NO];
[pool release];
}
- (void)setImageForTitleLogo:(NSData *)imgData
{
// This part is not strictly necessary
// but it's a nice way to wrap a method that needs to happen on the main thread.
if ([NSThread isMainThread])
{
// make the image (i'm assuming you meant loadingImage to be a local scope variable)
UIImage *loadingImage = [UIImage imageWithData:imgData];
// make sure the button still exists
// also make sure you're setting any references to this button to nil when you're releasing and making new views
// so that you're not addressing a button that's been released
// (assigning the image to the button will cause the button to retain it for you)
if (titleLogoImage != nil)
titleLogoImage.image = loadingImage;
}
else
{
[self performSelectorOnMainThread:#selector(setImageForTitleLogo:) withObject:imgData waitUntilDone:NO];
}
}
You're doing weird stuff.
NSURL *url = [[NSURL alloc] init];
means you create an NSURL object, which you own.
url = [NSURL URLWithString:logoPath];
This means you create another NSURL object, which is autoreleased. The NSURL you just created, just leaks. The same goes for the NSData here.
The loadingImage must be retained by titleLogoImage, or it will be deallocated on the drain of your NSAutoReleasePool. What is titleLogoImage and does it retain image?
edit ps: what also disturbes me, is that loadingImage is not confined to the scope of the function. To cut things short:
NSURL *url = [NSURL URLWithString:logoPath];
NSData *data = [NSData dataWithContentsOfURL:url];
titleLogoImage.image = [UIImage imageWithData:data];
may save some headaches, at least.
There is nothing in the posted code that would trigger a crash. Depending on how titleLogoImage is defined, it might be affects by the autorelease.
However, beyond the problems outlined by mvds, you have no pressing needs for a localized autorelease pool. It will do nothing here but cause you trouble.
Autorelease pools are dangerous and not for beginners. They will kill any autoreleased objects in them. You generally only create your own pool when you are rapidly creating a large number of memory intensive objects. That does not appear to be the case here.
Despite the attention given them, custom pools are seldom used. After over a decade Apple API work, I can probably count on my fingers the number of times I have used my own custom pool.

NSData release is not reclaiming memory

iPhoneOS 3.2
I use NSKeyedUnarchiver's unarchiveObjectWithFile: to load a custom object that contains a single large NSData and another much smaller object. The dealloc method in my custom object gets called, the NSData object is released, its retainCount == 1 just before. Physical memory does not decrement by any amount, let alone a fraction of the NSData size, and with repetition memory warnings are reliably generated: I have test until I actually received level 2 warnings. =(
NSString *archivePath = [[[NSBundle mainBundle] pathForResource:#"lingering"]
ofType:#"data"] retain];
lingeringDataContainer = [[NSKeyedUnarchiver unarchiveObjectWithFile:archivePath] retain];
[archivePath release];
[lingeringDataContainer release];
and now the dealloc....
- (void) dealloc {
[releasingObject release];
[lingeringData release];
[super dealloc];
}
Before release:
(gdb) p (int) [(NSData *) lingeringData retainCount]
$1 = 1
After:
(gdb) p (int) [(NSData *) lingeringData retainCount]
Target does not respond to this message selector.
First, you're retaining and releasing objects which do not need to have that happen to them. Here's the cleaned up code:
NSString *archivePath = [[NSBundle mainBundle] pathForResource:#"lingering"]
ofType:#"data"]; // Do not retain again.
lingeringDataContainer = [NSKeyedUnarchiver unarchiveObjectWithFile:archivePath]; // Do not retain again.
// Do not release, because archivePath is already autoreleaed: [archivePath release];
// Again, this is already autoreleased: [lingeringDataContainer release];
Or more simply:
NSString *archivePath = [[NSBundle mainBundle] pathForResource:#"lingering"]
ofType:#"data"];
lingeringDataContainer = [NSKeyedUnarchiver unarchiveObjectWithFile:archivePath];
Second, where's the rest of the code? It's probably something else which is being retained or cached somewhere else.
When are you checking the memory usage? Is it just after the code snippet you posted? archivePath and lingeringDataContainer are both autoreleased. They will not be deallocated until (at least) the autorelease pool is drained (usually at the end of the current event). There may also be a lot of other internal stuff that has been autoreleased and won't go away until the pool is drained.
Try doing this:
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; // <==
NSString *archivePath = [[[NSBundle mainBundle] pathForResource:#"lingering"]
ofType:#"data"] retain];
lingeringDataContainer = [[NSKeyedUnarchiver unarchiveObjectWithFile:archivePath] retain];
[pool release]; // <==
[archivePath release];
[lingeringDataContainer release];