I posted another question similar. This is my old code as some ppl say it would be even better, but there i didnt found a solution to release the allocated memory.
imageArray_danceright = [[NSArray alloc] initWithObjects:
[UIImage imageNamed:#"FrankieDanceRetime_0001.jpg"],
.. 40 images
[UIImage imageNamed:#"FrankieDanceRetime_00040.jpg"],nil];
imageArray_danceleft = [[NSArray alloc] initWithObjects:
[UIImage imageNamed:#"FrankieDanceRetime_0041.jpg"],
.. 40 images
[UIImage imageNamed:#"FrankieDanceRetime_00080.jpg"],nil];
imageArray_stand= [[NSArray alloc] initWithObjects:
[UIImage imageNamed:#"FrankieSingtRetime_0001.jpg"],
[UIImage imageNamed:#"FrankieSingtRetime_0002.jpg"],
[UIImage imageNamed:#"FrankieSingtRetime_0003.jpg"],nil];
//start animation
myimageview.animationImages = imageArray_stand;
myimageview.animationDuration = 0.23;
myimageview.contentMode = UIViewContentModeBottomLeft;
myimageview.animationRepeatCount = 0.0;
myimageview.image = [myimageview.animationImages objectAtIndex:1];
[myimageview startAnimating];
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
touch = [[event allTouches] anyObject];
if ([touch view] == overlay_fuesserechts) {
[myimageview setAnimationImages:imageArray_danceright];
myimageview.animationDuration = 2.0;
myimageview.contentMode = UIViewContentModeBottomLeft;
myimageview.animationRepeatCount = 1;
[myimageview startAnimating];
}
if ([touch view] == overlay_fuesselinks) {
[myimageview setAnimationImages:imageArray_danceleft];
myimageview.animationDuration = 2.0;
myimageview.contentMode = UIViewContentModeBottomLeft;
myimageview.animationRepeatCount = 1;
[myimageview startAnimating];
}
Its works fine.. just when i look in Instrument/Allocation, it does not release the memory.
It starts with 8mb for the 'stand' anim, goes up to 32mb for fuesserechts and when i click fuesselinks it goes up to 55mb (i have 6 more anim.. so a few more and it just crash)
When I do set [myimageview setAnimationImages:nil]; (in touchesBegan) for each setAnimationImages ... i still does not release the Memory. All Allocatoins Overall bytes, still increase.
When I do set [myimageview.animationImages release]; in (touchesbegan) for each setAnimationImages... it even crash after a few touches.
Thanks
Chris
Ok, now I see your original code I think I see where the advice came from. Instead of imageNamed: you might want to use imageWithContentsOfFile: (as you did in your earlier question). The former caches its images whereas the latter does not. I'm not convinced this is your problem here though.
What is less clear is where this code fits into your bigger system. I presume the first stretch of code (all the imageNamed: calls) is in an init method? Is that the case?
Is the //start animation section really in the same method, or somewhere else. This is not clear because you then include your touchesBegan: method in its entirety.
You also don't show where myimageview is being created - and who owns it. If you create it within the same class then you should also be releasing it in dealloc. Talking of dealloc it seems to be missing from this version - was that only in the new version? You need it here (more so).
I know its hard to post snippets of code unambiguously - but in this case I think these are the things that need clarification.
If your setup code (the imageNamed: stretch) is being called every time that may well explain it - as might the lack of releasing myimageview.
In this code, it looks like you're possibly initializing three arrays each click but you never release them so the arrays just stack up in memory. Alternatively, you may not be actually retaining the arrays at all. I can't tell because code provided where the arrays are initialized has no context to the rest of the class.
You should make the arrays of images retained properties of the class so that you only initialize them once. Use the self. notation to access them properly so that they are retained. Release them only in the class' deallocation method.
Don't ever send a release to another object's properties. Each object should exclusively manage its own memory use. In this case sending the UIImageView's animationImages property release is a big error. It will almost always cause a crash.
As an aside, it's dangerous to initialize the arrays with a large numbers of of imageNamed calls. If something goes wrong with a particular image, you will have a hard time tracking the error down. Instead, use a mutable array and build the array with a for loop. Doing so will make the code more compact and make errors obvious.
Related
Happy November to all,
Well I tried Xcode Build and analyze on my project, and it showed some unusual leaks, which I couldn't quite accept with my knowledge of Objective C.
So I decided to put up a test project and ask here..
MemoryTestController.h
#interface MemoryTestController : UIViewController{
UIImageView *tstImageView;
}
#property(nonatomic,retain) UIImageView *tstImageView;
#end
MemoryTestController.m
#implementation MemoryTestController
#synthesize tstImageView;
- (void)viewDidLoad{
[super viewDidLoad];
self.tstImageView = [[UIImageView alloc] //<==This object is leaking
initWithFrame:<SomeFrame>];
self.tstImageView.image = [UIImage imageNamed:#"SomeImage.png"];
[self.view addSubview:tstImageView];
[tstImageView release];
}
-(void)dealloc{
[tstImageView release];
[super dealloc];
}
#end
When I try Build and analyze, clang static analyzer say
Potential leak of an object at line xx
And the culprit line is
self.tstImageView = [[UIImageView alloc]initWithFrame:<SomeFrame>];
I think I am releasing once for every time I am allocing/retaining. Am I missing something, or Static analyzer has some bugs?
EDIT : Is there any leak there?
Well I run the above project using Leak tool in instrument..It didn't show any leak even though I tried many times..Whom should I believe? Static analyzer or Leak instrument?
your problem is how you release it:
- (void)viewDidLoad{
[super viewDidLoad];
self.tstImageView = [[UIImageView alloc] //<==This object is leaking
initWithFrame:<SomeFrame>];
self.tstImageView.image = [UIImage imageNamed:#"SomeImage.png"];
[self.view addSubview:tstImageView];
[tstImageView release]; // << here
}
you should do it this way:
- (void)viewDidLoad{
[super viewDidLoad];
UIImageView * imageView = [[UIImageView alloc] initWithFrame:<SomeFrame>];
imageView.image = [UIImage imageNamed:#"SomeImage.png"];
self.tstImageView = imageView;
[imageView release];
[self.view addSubview:self.tstImageView];
}
The checker is correct because it cannot assume that the variable is identical to the one you set. Therefore, the form you use in the OP could introduce a reference count imbalance because the ivar's value may not be what you assigned to it by the time you message release upon the ivar.
These cases are not likely for a UIImageView, and quite unlikely in the context of your program, but these examples should give you an idea as to why the checker assumes that object->ivar associations shall not be trusted:
Between creation of the image view and the message to release it via the ivar, you have:
self.tstImageView = [[UIImageView alloc] initWithFrame:<SomeFrame>];
self.tstImageView.image = [UIImage imageNamed:#"SomeImage.png"];
[self.view addSubview:tstImageView];
1) assignment of the image view via the setter
2) access of the image view via the getter
3) direct access of the ivar, when adding to self.view
the setter may have taken a copied or used a cached value. UIImageView is a bad example, but the checker does not know how types are generally passed around - even if it did, it would (at times) make unsafe assumptions.
the simplest example would be:
- (void)setName:(NSString *)inName {
NSString * prev = name;
if (inName == prev) return;
if (0 == [inName count]) name = #"";
else name = [inName copy];
[prev release];
}
the value held by the ivar could change in the meantime. not likely an issue in this case, but let's say that adding the image view as the subview could end up calling back and altering self in the process/effect of adding the subview, and replacing or removing the image view you passed. In that case, the variable view you passed would leak and the view it replaced it with would have a negative imbalance.
Neither of those are likely to happen in your example, but it does happen in real world programs, and the checker is correctly evaluating based on locality, not property (the checker can't assume much of what happens inside a method call). It also encourages one good idiomatic style in this case.
EDIT : Is there any leak there?
Well I run the above project using
Leak tool in instrument..It didn't shown any leak even though I tried
it many times..Whom should I believe? Static analyzer or Leak
instrument?
The static analyzer says there is a potential leak because it is unable to guarantee the reference/allocation it follows is correctly retained/released. You can guarantee that reference counting is correct and please the static analyzer by changing you program to look like I wrote it in my example.
The way you have written it has made it impossible for the analyzer to follow the reference.
If you have no leaks and no zombies, then there is not a leak. But the solution is easy to fix - and programs have a way of changing during development. It's much easier to use the form I posted so it is easier for the toolset and for you to verify the program is correct. The static analyzer is not always correct, but you should adjust your programs to please it because static analysis is very useful. The program I posted is also easier for a human to understand and confirm that it is correct.
when you declare a property with retain like this
#property(nonatomic,retain) UIImageView *tstImageView;
a setter is added that will incr the retainCount when you assign to the property. When you do as below the object you created has already a retainCount == 1
self.tstImageView = [[UIImageView alloc]
initWithFrame:<SomeFrame>];
so the tstImageView object has 2 in retainCount.
do instead
UIImageView* view = [[UIImageView alloc] initWithFrame:<SomeFrame>];
self.tstImageView = view;
[view release];
then, although unrelated to your leak when you release it write like this instead
self.tstImageView = nil;
since the setter will then will properly set the retainCount
I have an iPad app, which is children's book. You navigate from one page to the next by calling this action, which essentialy fades out the current page and fades in the next page, then fills the three stack UIImageViews with the next row of the NSArray, so it's prepared to complete the action for the next page:
-(void)delayedMethod{
[leftButton setAlpha:1];
[pageImageNext setAlpha:0];
[pageImage setAlpha:1];
[pageImageBack setAlpha:1];
NSString *imageExtension = #".jpg";
NSString *audioExtension = #".wav";
if (activePage == thePages.count/3)
{
activePage = 1;
}
else
{
activePage = activePage + 1;
}
NSInteger row = 0;
if(activePage == 0)
{
row = activePage;
}
else
{
row = ((activePage) * 3);
}
[leftButton setAlpha:1];
pageImageBack.image = [UIImage imageNamed:[NSString stringWithFormat:#"%#%#", [thePages objectAtIndex:row+0], imageExtension]];
pageImage.image = [UIImage imageNamed:[NSString stringWithFormat:#"%#%#", [thePages objectAtIndex:row+1], imageExtension]];
pageImageNext.image = [UIImage imageNamed:[NSString stringWithFormat:#"%#%#", [thePages objectAtIndex:row+2], imageExtension]];
[UIImageView beginAnimations:NULL context:NULL];
[UIImageView setAnimationDuration:.5]; // you can set this to whatever you like
/* put animations to be executed here, for example: */
[leftButton setAlpha:0];
[rightButton setAlpha:0];
[leftButton setAlpha:1];
[rightButton setAlpha:1];
leftButton.hidden = NO;
/* end animations to be executed */
[UIImageView commitAnimations]; // execute the animations listed above
[imageExtension release];
}
The NSArray is loaded in this action, which is called in the ViewDidLoad:
-(void)loadPages
{
thePages = [[NSArray alloc] initWithObjects:
// How many stacked images do we need to get fade in and outs? Also add column fo
#"page0",#"page0",#"page1",
#"page0",#"page1",#"page2",
#"page1",#"page2",#"page3",
#"page2",#"page3",#"page4",
#"page3",#"page4",#"page5",
#"page4",#"page5",#"page6",
#"page5",#"page6",#"page7",
#"page6",#"page7",#"page8",
#"page7",#"page8",#"page9",
#"page8",#"page9",#"page10",
#"page9",#"page10",#"page11",
#"page10",#"page11",#"page12",
#"page11",#"page12",#"page13",
#"page12",#"page13",#"page14",
#"page13",#"page14",#"page15",
#"page14",#"page15",#"page16",
#"page15",#"page16",#"page17",
#"page16",#"page17",#"page18",
#"page17",#"page18",#"page19",
#"page18",#"page19",#"page20",
#"page19",#"page20",#"page21",
#"page20",#"page21",#"page22",
#"page21",#"page22",#"page23",
#"page22",#"page23",#"page24",
#"page23",#"page24",#"page25",
#"page24",#"page25",#"page26",
#"page25",#"page26",#"page27",
#"page26",#"page27",#"page27",
nil];
}
It all works just fine until about the 10-12th page when I start to get memory warnings in the console and usually a crash.
I am pretty sure it is just a matter of releasing the three large UIImageViews at the right time, but I can't figure out when...I've tried a number of different spots in the code.
I was doing an app like this, where I had a lot of image views and labels that the user could change. I got warnings and crashes all the time. The only thing that seemed to fix it all was to make them all properties. Everything I wanted to hang on to on a certain view I had to make a property. That took care of it nicely, otherwise it seemed like the OS freaked out that I had to much allocated, and would send memory warnings which would release stuff, and then when the app tried to access them it would crash. See if making your pageImageNext, pageImage , pageImageBack properties works.
Make sure you are doing a [thePages release]]; in the dealloc method of the view controller. Not releasing that will definitely cause memory issues.
Also have you made the imageviews retained properties in the view controller? If so, you need to release them in the dealloc as well.
As for memory warnings, you can unset the imageviews in didRecieveMemoryWarning and then just add in a check to re-create them as needed.
The code:
[imageExtension release];
Is incorrect and should be deleted. "imageExtension" is allocated on the stack, and will go away when the method exits. Only release things that you have alloc'd.
Do you have just one of these types of ViewControllers? Or one for each page?
#sasquatch #YuzaKen #MishieMoo If I simply set self.pageImage = nil; in the dealloc, as you suggested, won't that only release the memory when a user leaves the ViewController?
I feel like I need to be releasing the UIImageViews as I move down the rows of the array, when I replace the contents of the UIImageView with a new image, no?
So I am making an app really quick, and even though it isn't the best solution, it appears to be working for the most part. So I have a simple image view that pulls an image out of an NSMutableArray arr. I create the array and populate it inside of ViewDidLoad in this manner:
arr = [[NSMutableArray alloc] init];
[arr addObject:[UIImage imageNamed:#"181940jpg"]];
[arr addObject:[UIImage imageNamed:#"168026.jpg"]];
[arr addObject:[UIImage imageNamed:#"168396.jpg"]];
[arr addObject:[UIImage imageNamed:#"168493_.jpg"]];
ANd I continue doing that for 130 images. Obviously this is a big array. I don't know if this is like a really bad way to do it, but if it is, I am open to suggestions! As I go through the array with some simple back and forward buttons pulling images out of the array based on a simple counter variable things work ok until image 45-ish. The app breaks down and the console says this:
* ERROR: ImageIO 'ImageProviderCopyImageBlockSetCallback' header is not a CFDictionary...
Would it help if I broke my images up into separate arrays? Am I just putting too much into the array? What am I missing here, trust me, I am all ears.
Thanks
EDIT: Here is some more information
This is how I am sifting through the array, using a UISegmentedControl set on the top of the screen:
-(void) pickedOne{
if(segmentedControl.selectedSegmentIndex == 1){
NSLog(#"hey");
if(position < [arr count]-1){
position++;//This is my global counter variable
UIImage * img = [arr objectAtIndex:position];
[imageView setImage:img];
[img release];
}
}else if(segmentedControl.selectedSegmentIndex ==0){
if(position >0){
position--;
UIImage * img = [arr objectAtIndex:position];
[imageView setImage:img];
[img release];
}
}
}
It doesn't appear to be a problem with memory management, but then again, I don't consider myself a pro at that by any means...
In terms of the mutable array, what you put into it is just a pointer to some other object. It is those other objects you have to worry about and, yes, you have too many of them (more likely than not).
ERROR: ImageIO 'ImageProviderCopyImageBlockSetCallback'
header is not a CFDictionary...
Would it help if I broke my images up
into separate arrays? Am I just
putting too much into the array? What
am I missing here, trust me, I am all
ears.
That sounds more like you have an over-release problem and are passing something bogus to the ImageIO APIs.
And, in fact, that is exactly what you have:
UIImage * img = [arr objectAtIndex:position];
[imageView setImage:img];
[img release];
That release is spurious; it does not balance a retain anywhere in your code. objectAtIndex: does not return a retained object and the UIView will take care of retaining/releasing the image internally.
Remove that release (and the other one, too)!
You still need to worry about memory consumption. At a size of 42K each (not an unreasonable size, but entirely made up), 130 images will weigh in at ~6MB or so, prior to any decompression or other expansion that occurs as a part of storage.
The devices are quite memory constrained.
I've read a lot of UIScrollView with UIImageView threads here or other googled pages. But I still cannot get the problem I'm confronting. I'm having a cold right now. Hope I can still make it clear, lol. Here is the problem:
I'm building one app which mainly uses UIScrollView to display a few images. Here the amount counts, not the size, which is averagely 100KB(I even converted PNG to jpg, not sure whether it helps or not). With no more than 10 images, my app crashes with memory warning. This is the first time I encounter memory issue, which surprised me as the compiled app is less than 10MB.
At the very beginning, I load all the images on launch, looping all names of image files and do
UIImageView *imageView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:imgName]];
[scrollview addSubview:imageView];
[imageView release];
If I'm right, I think after launch, all the images are in memory, right? But the funny thing here is, the app could launch without any problem(at most a level 1 memory warning). After I scroll a few images, it crashed. I checked leaks for sure and also allocations. No leak and allocation almost had no change during scrolling.
So, is there something special done by imageNamed rather than cache?
And then, yes, I turned to lazy load.
For fear of checking page and loading images on demand might jerk the scrolling(which was proved true), I used a thread which runs a loop to check offset of the scroll view and load/unload images.
I subclassed UIImageView by remembering the image name. It also contains loadImage and unloadImage which will be executed on that thread.
- (void)loadImage {
/if ([self.subviews count] == 0) {
UIImageView iv = [[UIImageView alloc] initWithImage:[UIImage imageNamed:self.imageName]];
[self performSelectorOnMainThread:#selector(renderImage:) withObject:iv waitUntilDone:NO];
//[self addSubview:iv];
[iv release];
}*/
if (self.image == nil) {
//UIImage *img = [UIImage imageNamed:self.imageName];
UIImage *img = [[UIImage alloc] initWithContentsOfFile:[[NSBundle mainBundle] pathForResource:[self.imageName stringByDeletingPathExtension] ofType:[self.imageName pathExtension]]];
// image must be set on main thread as UI rendering is main thread's responsibility
[self performSelectorOnMainThread:#selector(renderImage:) withObject:img waitUntilDone:NO];
[img release];
}
}
// render image on main thread
- (void)renderImage:(UIImage*)iv {
//[self addSubview:iv];
self.image = iv;
}
(void)unloadImage {
self.image = nil;
//[(UIView*)[self.subviews lastObject] removeFromSuperview];
}
You can see the commented code that I've played with.
In unloadImage, if I write [self.image release], then I get EXC_BAD_ACCESS, which is unexpected, as I think alloc and release are matched here.
The app still crashes with no leak. The initWithContentsOfFile version even crashed earlier than imageNamed version, and made the scrolling not that smooth.
I run the app on device. By checking allocations, I found imageNamed version used much less memory than initWithContentsOfFile version, though they both crash. Instruments also showed that the allocated images were 2,3 or 4, which indicated the lazy load did do his job.
I checked PhotoScroller of WWDC2010, but I don't think it solvs my problem. There is no zooming or huge picture involved.
Anybody helps! Thank you in advance.
The crash log says nothing. The app crashes mostly after memory warning level = 2. And if run on simulator, there will be no problem.
It doesn't matter which format do you use for your images. They're converted to bitmaps when you display them.
I'd suggest to use the technique similar to that one which is used by UITableView (hide the image and free the memory it uses when it disappears from the screen and instantiate the image only when you need to show it).
As an alternate way – if you need to show these images in a grid – you might take a look to a CATiledLayer.
Anyhow, loading all the images to the memory is not the best idea :)
You can load all the images to an array. And you can design a view having one image view and try the below code:
array name: examplearray and view name :exampleview
-(void)updateImagesInScrollView
{
int cnt = [examplearray count];
for(int j=0; j< cnt; ++j)
{
NSArray *nibContents = [[NSBundle mainBundle] loadNibNamed:#"exampleview"
owner:self
options:nil];
UIView *myView = [nibContents objectAtIndex:0];
exampleview * rview= (exampleview *)myView;
/* you can get your iamge from the array and set the image*/
rview.imageview.image = yourimage;
/*adding the view to your scrollview*/
[self.ScrollView addSubview:rview];
}
/* you need to set the content size of the scroll view */
self.ScrollView.contentSize = CGSizeMake(X, self.mHorizontalScrollView.contentSize.height);
}
Im developing an app for an iPhone and I found that the following code is causing the memory allocation to increment.
-(UIImage *)createRecipeCardImage:(Process *)objectTBD atIndex:(int)indx
{
[objectTBD retain];
// bringing the image for the background
UIImage *rCard = [UIImage imageNamed:#"card_bg.png"];
CGRect frame = CGRectMake(00.0f, 80.0f, 330.0f, 330.0f);
// creating he UIImage view to contain the recipe's data
UIImageView *imageView = [[UIImageView alloc] initWithFrame:frame];
imageView.image = rCard;
[rCard release];
imageView.userInteractionEnabled = YES;
float titleLabelWidth = 150.0;
float leftGutter = 5.0;
float titleYPos = 25.0;
float space = 3.0;
float leftYPos = 0;
// locating Title label
float currentHeight = [self calculateHeightOfTextFromWidth:objectTBD.Title :titleFont :titleLabelWidth :UILineBreakModeWordWrap];
UILabel *cardTitle = [[UILabel alloc]initWithFrame:CGRectMake(leftGutter, titleYPos, titleLabelWidth, currentHeight)];
cardTitle.lineBreakMode = UILineBreakModeWordWrap;
cardTitle.numberOfLines = 0;
cardTitle.font = titleFont;
cardTitle.text = objectTBD.Title;
cardTitle.backgroundColor = [UIColor clearColor];
[imageView addSubview:cardTitle];
[cardTitle release];
leftYPos = titleYPos + currentHeight + space;
// locating brown line
UIView *brownLine = [[UIView alloc] initWithFrame:CGRectMake(5.0, leftYPos, 150.0, 2.0)];
brownLine.backgroundColor = [UIColor colorWithRed:0.647 green:0.341 blue:0.122 alpha:1.0];
[imageView addSubview:brownLine];
[brownLine release];
leftYPos = leftYPos + 2 + space + space + space;
// creating the imageView to place the image
UIImageView *processPhoto = [[UIImageView alloc] initWithFrame:CGRectMake(leftGutter, leftYPos, 150, 150)];
if((uniqueIndex == indx) && (uniqueImg.imageData != nil))
{
if([uniqueImg.rcpIden isEqualToString:objectTBD.iden])
{
objectTBD.imageData = [NSString stringWithFormat:#"%#", uniqueImg.imageData];
[recipesFound replaceObjectAtIndex:indx withObject:objectTBD];
NSData * imageData = [NSData dataFromBase64String:objectTBD.imageData];
UIImage *rcpImage = [[UIImage alloc] initWithData:imageData];
[imageData release];
processPhoto.image = rcpImage;
[rcpImage release];
}
}
else if(objectTBD.imageData != nil)
{
NSData * imageData = [NSData dataFromBase64String:objectTBD.imageData];
UIImage *rcpImage = [[UIImage alloc] initWithData:imageData];
processPhoto.image = rcpImage;
[rcpImage release];
[decodedBigImageDataPointers addObject:imageData];
}
else
{
UIImage * rcpImage = [UIImage imageNamed:#"default_recipe_img.png"];
processPhoto.image = rcpImage;
[rcpImage release];
}
NSlog(#" Process Photo Retain Count %i", [processPhoto retainCount]); // this prints a 1
[imageView addSubview:processPhoto];
NSlog(#" Process Photo Retain Count %i", [processPhoto retainCount]); // this prints a 2!!!!
//[processPhoto release]; // this line causes an error :(
// converting the UIImageView into a UIImage
UIGraphicsBeginImageContext(imageView.bounds.size);
[imageView.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *viewImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
[objectTBD release];
for(UIView *eachSubview in imageView.subviews)
{
[eachSubview removeFromSuperview];
NSLog(#"each subview retainCount %i despues", [eachSubview retainCount]);
// here I find that the processPhoto view has a retain count of 2 (all other views have their retain count in 1)
}
return viewImage;
}
When I checked at the instruments object allocation I found that the "GeneralBlock-9216" growing up.
Breaking down the row I found that every time I call this code, one instance of:
2 0x5083800 00:18.534 ImageIO initImageJPEG
is being allocated. Checking the call stack, the following line is highlighted:
UIImage * objImage = [UIImage imageWithData:imageData];
Any help to find what the error is?
As TechZen said, the imageWithXXX: methods cache the image inside of them while you run the program (though you release the instances after using). I recommend initWithXXX: and release API sets instead of imageWithXXX:.
Well, if you embed several debug log on your source code, check how many times is it called, and check the retain count of the instances.
As far as I can explain, that is all.
I hope you will solve the problem.
Does anyone have an answer for this? It's tearing me apart trying to figure out why this image information keeps lingering. I've tried every solution.
The situation:
Images get downloaded and stored to the device, then loaded with imageWithContentsOfFile (or even initWithContentsOfFile, which doesn't help either). When the view goes away, the images don't, but they don't show up as leaks, they're just this initImageJPEG Malloc 9.00 KB that never goes away and keeps ramping up.
UPDATE: I believe I've figured this out: Check to make sure everything is actually getting dealloc'd when you're releasing whatever the parents (and/or grandparents) and etc of the images are. If the parents don't get deallocated, they never let go of their children images, and whatever data was in those images sticks around. So check retain counts of parent objects and make sure that everything's going away all the way up whenever you release the view at the top.
A good way to check for this is to put NSLogs into custom classes' dealloc methods. If they never show up, that object isn't going away, even though the reference to it might, and it (and whatever its subviews and properties are) will never ever disappear. In the case of images, this means a pretty sizable allocation every time that object is generated and never deallocated. It might not show up in leaks, especially if the parent of the topmost object you're thinking you're releasing but actually aren't persists and doesn't itself ever deallocate.
I hope this helps. It'll be useful to take some time to read through your code with a fine-toothed comb to make sure you're allocating and releasing things properly. (Search for "alloc]", start at the top of the file, and work your way down to make sure you're releasing and that the release isn't inside of some if() or something.)
Also, running "Build and Analyze" might lock up your machine for a bit, but its results can be really helpful.
Good luck!
I think you're seeing UIImage cacheing images. There used there used to be a method something like initWithData:cache that let you turn the cacheing off. Now I think the system always caches the images automatically behind the scenes even after you've deallocted the specific instances.
I don't think its an error on your part. I think it's the system keeping data around in the OpenGl subsystem. Unless it causes a major leak, I don't think it is a problem.