PDA

View Full Version : iPhone memory leaking message..




sujithkrishnan
Jun 27, 2008, 07:11 AM
HI all..

In my app, when i start it , consoel is showing a message like this..

Its a memory laking warning i guess...

2008-06-27 17:18:52.098 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x148e20 of class UICFFont autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30bac504 0x30b5a1dc 0x30b5a248 0x30b5a3cc 0x30b085e0 0x30afe088 0x30b02a00 0x30b02ee8 0x535d 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.171 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x14d7b0 of class UICGColor autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30bae790 0x30a7f5f4 0x30a7f6e8 0x30b08600 0x30afe088 0x30b02a00 0x30b02ee8 0x535d 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.217 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x14d400 of class UICGColor autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30bae790 0x30a7f5f4 0x30a7f180 0x30b08618 0x30afe088 0x30b02a00 0x30b02ee8 0x535d 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.232 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x14f5c0 of class UICFFont autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30bac504 0x30b08670 0x30afe088 0x30b02a00 0x30b02ee8 0x535d 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.300 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x14f5c0 of class UICFFont autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30b5b90c 0x30b5d064 0x30b0aa60 0x30b0d7d4 0x30b00acc 0x30b00c74 0x30b061dc 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.310 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x27dc8 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30b5ad14 0x30b5d07c 0x30b0aa60 0x30b0d7d4 0x30b00acc 0x30b00c74 0x30b061dc 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.346 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x151550 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x30692d6d 0x30a734d8 0x30a732f0 0x30b063f8 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.356 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x152690 of class NSCFDictionary autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x3025ac79 0x30a7350c 0x30a732f0 0x30b063f8 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.380 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x10d960 of class CAContextImpl autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x31ebe764 0x30a735ac 0x30a732f0 0x30b063f8 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.408 mySampleApp[592:4403] *** _NSAutoreleaseNoPool(): Object 0x109d30 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x306e36ef 0x30671c8f 0x30671c5b 0x3026f9cb 0x31ebf26c 0x30a774a8 0x30a6330c 0x30b064e8 0x30b00f94 0x30b00ff4 0x30b030dc 0x54a1 0x306761f1 0x306760bf 0x3143cc51)
2008-06-27 17:18:52.443 mySampleApp[592:20b]


What it means xactly???

The classes that mentioned are not used by me directly...
How to rectify this????

May be because of this my app is crashing in device, but works fine in simulator....



Mac Player
Jun 27, 2008, 07:25 AM
It's means that somewhere in your code your are allocating autoreleased objects without having an auto release pool to release them at the end of the event loop.

Enuratique
Jun 27, 2008, 09:21 AM
Try running your application with Instruments' Leak Detector. You can go Run > Start with Performance Tool > Leaks and it should help identify what's leaking in your program. Try doing this with the simulator and not on the device to collect leak data.

gnasher729
Jun 27, 2008, 10:51 AM
Read the documentation for "AutoReleasePool". Seriously. If you don't know what an AutoReleasePool is and when you have to use it, there is no way you can write an application that will run for any length of time. It is not very difficult at all, but you need to know and understand it.

sujithkrishnan
Jun 30, 2008, 12:17 AM
Try running your application with Instruments' Leak Detector. You can go Run > Start with Performance Tool > Leaks and it should help identify what's leaking in your program. Try doing this with the simulator and not on the device to collect leak data.

Can u tell me how to identify which object is causiong memory leak from instruments ????
I am gettign some peaks in "memory leak" view in instruments...
How to gather much info from that point??

Also... i didnt mentioned any autorelease in the above context...
Is it bcoz of factory-constructor ?
Whether fac-constructors call autorelease aftre the scope???

Is the outermost autorelelase pool is not enough???

Also i am having a thread do i want to put it in a autorelease pool???

Moreover the classes mentioned in Log is not used by me also...

Enuratique
Jun 30, 2008, 10:35 AM
Can u tell me how to identify which object is causiong memory leak from instruments ????
I am gettign some peaks in "memory leak" view in instruments...
How to gather much info from that point??

Also... i didnt mentioned any autorelease in the above context...
Is it bcoz of factory-constructor ?
Whether fac-constructors call autorelease aftre the scope???

Is the outermost autorelelase pool is not enough???

Also i am having a thread do i want to put it in a autorelease pool???

Moreover the classes mentioned in Log is not used by me also...

Well, I've never had to track down leaks so I'm not quite sure what the process is but apparently some other intrepid soul out there has figured it out and blogged (http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/) about it.

This should help you identify specifically what objects are leaking and in what call stack context they're leaking in.

I know this doesn't sound like much fun, but do a global search on your project in XCode looking for the word alloc. For every time you alloc an object, you need to be especially careful that you release the object you allocated before overwriting the pointer's value with a new allocation. This is the most common source of leaks as you're orphaning the original allocation. Also be sure that if the pointer is global to the class that you call release on it in your class' dealloc method. EVERY class you write should have a dealloc method whether it needs one or not which (at the very least) calls [super dealloc] at the end. This is just good practice.

Do the same search for the word 'retain'. I'm assuming you're making heavy use of autoreleased objects (which is fine and good, that's the intent of autorelease - to make your life easier) but if you've retained an object that was autoreleased by the API, you need to release it manually as if you had called alloc on it.

Regarding your questions, it can be assumed that any type of pointer that is returned by an iPhone SDK method has had autorelease called on it before being returned to you. This includes the "static" or class level constructors (the ones prefixed with init you will typically call in conjunction with alloc). And the main / outermost autorelease pool should be sufficient. I would use a smaller scoped autorelease pool when you have a subroutine that allocates and releases A LOT of memory (say allocate some chunk of memory at the beginning of a loop with autorelease) but even then the only benefit is not having all these objects in the outermost autorelease pool, potentially living there for a while when they're no longer needed by the program and potentially causing a low memory warning to be sent to your app. I don't know enough about threading on iPhone - so I can't answer definitively whether a new thread's allocations go in the main/outermost autorelease pool.

HTH,

Enuratique

newb16
Jun 30, 2008, 02:46 PM
Also... i didnt mentioned any autorelease in the above context...
Is it bcoz of factory-constructor ?
Whether fac-constructors call autorelease aftre the scope???

Is the outermost autorelelase pool is not enough???

Also i am having a thread do i want to put it in a autorelease pool???

A bit mystified with bcoz, however, it doesn't matter whether it was constructed in factory or not - it is executed in context of your thread, and if it is not main thread yr need to create said pool manually (as http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html (surprise...) states ). It is not the same as "put it(i.e. the thread) in a autorelease pool"

sujithkrishnan
Jul 2, 2008, 05:24 AM
A bit mystified with bcoz, however, it doesn't matter whether it was constructed in factory or not - it is executed in context of your thread, and if it is not main thread yr need to create said pool manually (as http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html (surprise...) states ). It is not the same as "put it(i.e. the thread) in a autorelease pool"

Okie...

But the leak-message went when i removed my "thread calling" which displays the alertview with activity indicator....

i called a method to display progress activity indicator in a alertview using
detachNewThreadSelector:@selector(progressViewMethod:) toTarget:self withObject:nil];

Why so???

I tried giving a autoreleasepool before the call, relased it after the call...

sujithkrishnan
Jul 3, 2008, 01:25 AM
Well, I've never had to track down leaks so I'm not quite sure what the process is but apparently some other intrepid soul out there has figured it out and blogged (http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/) about it.

This should help you identify specifically what objects are leaking and in what call stack context they're leaking in.

I know this doesn't sound like much fun, but do a global search on your project in XCode looking for the word alloc. For every time you alloc an object, you need to be especially careful that you release the object you allocated before overwriting the pointer's value with a new allocation. This is the most common source of leaks as you're orphaning the original allocation. Also be sure that if the pointer is global to the class that you call release on it in your class' dealloc method. EVERY class you write should have a dealloc method whether it needs one or not which (at the very least) calls [super dealloc] at the end. This is just good practice.

Do the same search for the word 'retain'. I'm assuming you're making heavy use of autoreleased objects (which is fine and good, that's the intent of autorelease - to make your life easier) but if you've retained an object that was autoreleased by the API, you need to release it manually as if you had called alloc on it.

Regarding your questions, it can be assumed that any type of pointer that is returned by an iPhone SDK method has had autorelease called on it before being returned to you. This includes the "static" or class level constructors (the ones prefixed with init you will typically call in conjunction with alloc). And the main / outermost autorelease pool should be sufficient. I would use a smaller scoped autorelease pool when you have a subroutine that allocates and releases A LOT of memory (say allocate some chunk of memory at the beginning of a loop with autorelease) but even then the only benefit is not having all these objects in the outermost autorelease pool, potentially living there for a while when they're no longer needed by the program and potentially causing a low memory warning to be sent to your app. I don't know enough about threading on iPhone - so I can't answer definitively whether a new thread's allocations go in the main/outermost autorelease pool.

HTH,

Enuratique


But i am getting memory-leaking peaks(instruments tool) in following part of code.. eventhough i relelase whatever i allocated, its still giving leaks..
Whats wrong here?



NSURL *url = [[NSURL alloc]initWithString:itemObject.iImg];

NSData *dataObj = [[NSData alloc]initWithContentsOfURL:url];
UIImage *img = [[UIImage alloc]initWithData:dataObj];
cell.image = img;
[img release];
[dataObj release];
[url release];



I tried giving following also, but it also showing leak...


cell.image = [UIImage imageFromData:[NSData dataFromURL:[NSURL urlFromString:myyURLString]]];


What i do to avoid the leak???

Also why my app fails to load / crashing on startup only sometimes???
Sometimes its exiting on the half-way also???
I am not asking the exact reason (as i am not telling you about my code), but i am asking for some general reasons for sucha behaviour...


Thanks

Enuratique
Jul 3, 2008, 10:44 AM
But i am getting memory-leaking peaks(instruments tool) in following part of code.. eventhough i relelase whatever i allocated, its still giving leaks..
Whats wrong here?



NSURL *url = [[NSURL alloc]initWithString:itemObject.iImg];

NSData *dataObj = [[NSData alloc]initWithContentsOfURL:url];
UIImage *img = [[UIImage alloc]initWithData:dataObj];
cell.image = img;
[img release];
[dataObj release];
[url release];



I tried giving following also, but it also showing leak...


cell.image = [UIImage imageFromData:[NSData dataFromURL:[NSURL urlFromString:myyURLString]]];


What i do to avoid the leak???

Honestly, I don't see anything wrong with either of those pieces of code... I guess I would go with the second approach personally, but I don't see where the leak would be occurring in either version. The only thing that comes to mind is that there is more going on in this method than what you pasted? Are you not releasing itemObject or any of its member variables? Perhaps you could post a screenshot of Instruments' leak objects tree?


Also why my app fails to load / crashing on startup only sometimes???
Sometimes its exiting on the half-way also???
I am not asking the exact reason (as i am not telling you about my code), but i am asking for some general reasons for sucha behaviour...


Thanks

It could be a lot of things, my guess is that a pointer has had release called on it one too many times and a piece of your code is trying to reference that pointer and you get a BAD_ACCESS exception - basically the iPhone OS force quits the application. You can see what's going on if you open the Debug Console before running the application to see why exactly the program isn't running. Another possibility is that if your application still has leaks and the code that's leaking occurs within a loop, it might be possible that you're application is eating up too much memory and your app delegate is sent the didReceiveLowMemoryWarning message. By default, the application will unload the UIView to free up memory... I would try implementing this method in your app delegate (calling [super didReceiveLowMemoryWarning] to make sure things still happen the way the phone expects) and put an NSLog statement just to see if that's the cause of the problem... Either way, you'll see the output in the Debug Console.

ElectricSheep
Jul 3, 2008, 12:14 PM
Okie...

But the leak-message went when i removed my "thread calling" which displays the alertview with activity indicator....

i called a method to display progress activity indicator in a alertview using
detachNewThreadSelector:@selector(progressViewMethod:) toTarget:self withObject:nil];

Why so???

I tried giving a autoreleasepool before the call, relased it after the call...

This is from Apples NSThread Class Reference (http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Reference.html#//apple_ref/occ/clm/NSThread/detachNewThreadSelector:toTarget:withObject:):

For non garbage-collected applications, the method aSelector is responsible for setting up an autorelease pool for the newly detached thread and freeing that pool before it exits. Garbage-collected applications do not need to create an autorelease pool.

progressViewMethod: must create an autorelease pool, and then release it when it finishes execution.