Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS Scrolling/Image memory leak...

Why would you release the image: you don't own it. Read my post above. Did you create the image with alloc/init or copy? No. So don't release it. It's autoreleased.

I think you need to read and fully understand the Cocoa Memory Management Guide as this is an absolutely fundamental concept. Really you should not be writing code at all until you are sure you know this.
 
robbieduncan said:
Why would you release the image: you don't own it. Read my post above. Did you create the image with alloc/init or copy? No. So don't release it. It's autoreleased.

I think you need to read and fully understand the Cocoa Memory Management Guide as this is an absolutely fundamental concept. Really you should not be writing code at all until you are sure you know this.
Click to expand...

actually that's part why I had thought I needed to release it, because I have initWithImage:image?

If it is autoreleased though I guess some other part of this code must have a leak in it :S

I'll have another read through of the Guide you've linked :)
 
MentalFabric said:
actually that's part why I had thought I needed to release it, because I have initWithImage:image?
Click to expand...

You create imageView with init. You do not create image with init. So you should, at some point, release imageView. But you said you put [image release]. Which you should not be doing. Accuracy and attention to detail are important.
 
robbieduncan said:
You create imageView with init. You do not create image with init. So you should, at some point, release imageView. But you said you put [image release]. Which you should not be doing. Accuracy and attention to detail are important.
Click to expand...

OK i put image release based on the UIImage alloc recommended earlier and confused myself a little, which I have now taken out - but imageView IS released and I still have a crash once I've opened the majority of the views, no matter in what order I open them.
Actually, now it crashes halfway through a view when paging to the next image, whereas before it would crash on trying to open the view...

Also, the Leaks performance tool no longer shows leaking UIImage(s), only two instances of open_handle_to_dylib_path, which I believe are a bug with main.m?

I'm still pretty stuck but I will read through the apple memory article again now...
 
I'm very confused as to what you're actually doing now.

And I wonder why you are still trying to do this:
Code: 
UIImage *image = [UIImage imageWithContentsOfFile:path];
when what I recommended you do was this:
Code: 
UIImage *image = [[UIImage alloc] initWithContentsOfFile:path];
?

There is a huge difference, in terms of memory management, between the imageWithContentsOfFile: class method and the initWithContentsOfFile: instance method.
 
dejo said:
I'm very confused as to what you're actually doing now.

And I wonder why you are still trying to do this:
Code: 
UIImage *image = [UIImage imageWithContentsOfFile:path];
when what I recommended you do was this:
Code: 
UIImage *image = [[UIImage alloc] initWithContentsOfFile:path];
?

There is a huge difference, in terms of memory management, between the imageWithContentsOfFile: class method and the initWithContentsOfFile: instance method.
Click to expand...

That was because the view crashes the app when I include [UIImage alloc] - and robbieduncan thought I was better off without it - did I just miss something from the header file perhaps? (for instance,
Code: 
UIImage *image;
and
Code: 
@property (nonatomic, retain) UIImage *image;
?
 
MentalFabric said:
That was because the view crashes the app when I include [UIImage alloc]...
Click to expand...
I asked you before where it was crashing and you said you were getting a "-[UIImage imageWithContentsOfFile:]: unrecognized selector" error. But nowhere does my recommended code call the imageWithContentsOfFile: class method.
 
dejo said:
I asked you before where it was crashing and you said you were getting a "-[UIImage imageWithContentsOfFile:]: unrecognized selector" error. But nowhere does my recommended code call the imageWithContentsOfFile: class method.
Click to expand...

Oooooh I am a complete moron, I managed to miss the change from imageWith to initWith :eek:

Thank you! :D
 
dejo said:
Remember:
Click to expand...

I still have a lot to learn - only 2-3 weeks in at the moment :) Got a few books on the topic, I should probably finish reading through them instead of just what I think is necessary :/

Unfortunately though, now the app crashes even sooner :eek:

Console now says:
Code: 
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
run
Running…
[Switching to thread 11779]
[Switching to thread 11779]
sharedlibrary apply-load-rules all
continue
Program received signal:**“EXC_BAD_ACCESS”.
(gdb)
Doesn't mean much to me :(
 
OK here's the whole view:

Code: 
#import "AboutViewController.h"
@implementation AboutViewController
@synthesize scrollView1;
const CGFloat kScrollObjHeight = 411.0;
const CGFloat kScrollObjWidth = 320.0;
const NSUInteger kNumImages**= 6;

- (void)layoutScrollImages
{
UIImageView *view = nil;
NSArray *subviews = [scrollView1 subviews];
// reposition all image subviews in a horizontal serial fashion
CGFloat curXLoc = 0;
for (view in subviews)
{
if ([view isKindOfClassUIImageView class]] && view.tag > 0)
{
CGRect frame = view.frame;
frame.origin = CGPointMake(curXLoc, 0);
view.frame = frame;
curXLoc += (kScrollObjWidth);
}
}
// set the content size so it can be scrollable
[scrollView1 setContentSize:CGSizeMake((kNumImages * kScrollObjWidth), 411)];
}

- (void)viewDidLoad
{
self.view.backgroundColor = [UIColor blackColor];

scrollView1.indicatorStyle = UIScrollViewIndicatorStyleWhite;
scrollView1.clipsToBounds = YES;**// default is NO, we want to restrict drawing within our scrollview
scrollView1.scrollEnabled = YES;
scrollView1.pagingEnabled = YES;
scrollView1.bounces = YES;
scrollView1.directionalLockEnabled = YES;
scrollView1.maximumZoomScale = 1.0;
scrollView1.minimumZoomScale = 1.0;
scrollView1.multipleTouchEnabled = YES;


NSUInteger i;
for (i = 1; i <= kNumImages; i++)
{
NSString *path = [[NSBundle mainBundle] pathForResource:[NSString 
stringWithFormat:@"image%d",i] ofType:@"png"];
UIImage *image = [[UIImage alloc] initWithContentsOfFile:path];
UIImageView *imageView = [[UIImageView alloc] initWithImage:image];
[image release];
/*
NSString *imageName = [NSString stringWithFormat:@"image%d.png", i];
UIImage *image = [UIImage imageNamed:imageName];
UIImageView *imageView = [[UIImageView alloc] initWithImage:image];
*/
// setup each frame to a default height and width, it will be properly placed when we call "updateScrollList"
CGRect rect = imageView.frame;
rect.size.height = kScrollObjHeight;
rect.size.width = kScrollObjWidth;
imageView.frame = rect;
imageView.tag = i; // tag our images for later use when we place them in serial fashion
[scrollView1 addSubview:imageView];
[imageView release];

}
[self layoutScrollImages];
}


- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
}
- (void)viewDidUnload {
[super viewDidUnload];
}
- (void)dealloc {
[scrollView1 release];
// [image release];
[AboutViewController release];
// [imageView release];
[self.view removeFromSuperview];
[super dealloc];
}
@end
 
Are you able to determine which line is causing the EXC_BAD_ACCESS? You might be best off stepping through the code to determine this.

EDIT: I'm running almost your exact code in a View-Based Template app and not getting any crashes. So, I would think that the cause is in code elsewhere in your app. I guess that makes it even more important to determine the exact line causing the crash.

Also, why are you releasing AboutViewController and removing the view from the superview in your dealloc? These are not normal here.

Oh, and your viewDidLoad does not call
Code: 
[super viewDidLoad];
Not a big deal in this case, but make it a habit to leave it in, just in case.
 
dejo said:
Are you able to determine which line is causing the EXC_BAD_ACCESS? You might be best off stepping through the code to determine this.

EDIT: I'm running almost your exact code in a View-Based Template app and not getting any crashes. So, I would think that the cause is in code elsewhere in your app. I guess that makes it even more important to determine the exact line causing the crash.
Click to expand...

I'm working through breakpoints on everything in the view and everything that loads the view but not finding anything...

You won't get the crashes unless you have around 15 of these views with an average of 6 pngs around 70KB in each. If I swap to average 50KB jpgs I don't get a crash.

The view that the app crashes on if you go through all views in order loads properly having stopped at all the breakpoints and apparently already loaded all the images. I page right and notice it's moving a little slowly - then when I page again the app crashes.

Also, why are you releasing AboutViewController and removing the view from the superview in your dealloc? These are not normal here.
Click to expand...

This was because the only thing I can think of that could be causing this crash outside of the view was the table view controller that opens it... although it is released there as soon as it's done, I thought maybe the views weren't unloading properly so I was playing around a bit out of my depth trying to release it within it's self... :/

As far as I can tell it must be either the images not releasing, or the whole views not releasing when the back button is pressed... it seems to me as though the images are loading twice in each view perhaps... once when it opens, and once again when i page right - but that's using the same logic that caused people to believe the earth to be at the center of the universe...
 
Oooh ok this time having loaded another smaller view beforehand, it's stopping at super didReceiveMemoryWarning and not letting me page... which makes sense to a degree. I just don't understand why anything from the previous views would still be loaded o_O
 
dejo said:
If you're willing, attaching a zipped project might give us better insight into what your code is actually doing.
Click to expand...

Had to think about that one! If this was an app I was only developing personally that wouldn't be a problem, but it's for the company I work for and full of copyrighted material, so until I figure this one out I think I'm just going to have to use the workaround...

Thanks for all your help though! It's quite a learning experience :D
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back