I am a beginner at this :)
I have an app which changes an image of a UIImageView when a button is pushed, each image is about 200 kb, when run in the simulator it runs ok, I can change the image many times with no problems.
When run on my device (ipod touch) it loads ok, it sluggishly gets through about 4 images and then it crashes. When I run it with the Allocations performance tool, it crashes when overall bytes reaches about 2.75 megs. Number of living allocations is about 8000 (is this high?).
My console reads this
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
I've also tried using the "leaks" performance tool and it doesn't find any leaks.
My .h file loads the image and uimageview like this:
#property(retain, nonatomic) IBOutlet UIImageView* myUIImageView;
#property(nonatomic, retain) UIImage *image;
Also, I release these like this:
- (void)dealloc {
[super dealloc];
[myUIImageView release];
[image release];
}
I also added in this, but it didn't seem to make any difference:
- (void)didReceiveMemoryWarning {
// Releases the view if it doesn't have a superview.
[super didReceiveMemoryWarning];
[myUIImageView release];
[image release];
// Release any cached data, images, etc that aren't in use.
}
I'm not sure what else to try at this point, any debugging techniques suggestions would be appreciated, also any pointers on how tackle memory issues like this would be hugely helpful,
thanks!
Also, sorry forgot to add the image changing code:
- (IBAction)myButton {
static NSUInteger counter = 0;
counter++;
if (counter == 1) {
myUIImageView.image = [UIImage imageNamed:#"image1.jpg"];
}
else {
myUIImageView.image = [UIImage imageNamed:#"image2.jpg"];
counter = 0;
}
}
Your image changing code looks fine, but I suggest these changes:
You should set myUIImageView to nil in your viewDidUnload method:
- (void)viewDidUnload {
// release retained subviews of main view
self.myUIImageView = nil;
}
In didReceiveMemoryWarning, you should set image to nil instead of sending a release:
self.image = nil;
Having [image release] in both didReceiveMemoryWarning and dealloc might cause a double release.
Also, don't release myUIImageView in didReceiveMemoryWarning.
Are you actually using the image ivar? It looks like you are assigning an image directly to the UIImageView. Having an unused ivar doesn't cause a problem, obviously, but I'm just wondering why it's there.
What code are you using to change the image? Make sure you are not re-alloc'ing the image or imageview.
Related
I have a strange issue .
I am currently working on a mail app and it used to crash randomly without and error or logs in my console . I checked my Crash Log it showed me Low Memory warning with jettisoned written next to my App.
So I suspect it's an memory issue and went back to trace my memory usage of my application.
I used allocation instrument to detect the overall usage and my application crashed when it's heap size was just 4.59 MB.
Instruments point towards a function where I am using MBProgressHUD indicator.
The culprit is this one line :
[appDelegate showHUDActivityIndicatorOnView:self.parentViewController.view whileExecuting:#selector(refreshInBackground) onTarget:self withObject:nil withText:#"Loading"];
If I replace this with
[self refreshInBackground] everything works fine no issues ..
Here is the code :
-(void) showHUDActivityIndicatorOnView:(UIView*)view whileExecuting:(SEL)method
onTarget:(id)target withObject:(id)object withText:(NSString*)label{
self.HUD = [[MBProgressHUD alloc] initWithView:view] ;
self.navigationController.navigationItem.hidesBackButton = YES;
[view addSubview:self.HUD];
self.HUD.delegate = nil;
self.HUD.labelText = label;
[self.HUD showWhileExecuting:method onTarget:target withObject:object animated:YES];
}
self.HUD is a property which is being retained.
With a slight modification is showWhileExecuting method as follows :
- (void)showWhileExecuting:(SEL)method onTarget:(id)target withObject:(id)object animated:(BOOL)animated {
MyAppdelegate *appDelegate = (MyAppdelegate *)[UIApplication sharedApplication].delegate;
if(!appDelegate.isRequestActive)
{
methodForExecution = method;
targetForExecution = [target retain];
objectForExecution = [object retain];
// Launch execution in new thread
taskInProgress = YES;
[NSThread detachNewThreadSelector:#selector(launchExecution) toTarget:self withObject:nil];
// Show HUD view
[self show:animated];
}
else {
[self done];
}
}
currently I have removed this from my app and it works fine now and it does not crashes even with the usage of 20 - 30 MB heap Memory .
I am not looking for an specific answer or solution here . What I am looking for ways to debug / techniques to debug the issue so that I can get to know what caused my app to crash .
Is it memory overflow . If that's the case then how can I use 20-30 MB right now.
If it's not an memory issue why does my crash reporter shows jettisoned next to my App name .
the culprit line ([appDelegate showHUDActivityIndicatorOnView:self.parentViewController.view whileExecuting:#selector(refreshInBackground) onTarget:self withObject:nil withText:#"Loading"])
Every time when I call this function some memory increases , because of some elements being cached . But when memory reached 4.5 MB ...this line cause it to crash
How do I get to the root cause of this issue . How do I figure out why iOS is killing my app the reason for jettisoned written next to my app
Any help or suggestions would be really appreciated .
Ok. The problem is I was adding the HUD progress bar on my view using
[view addSubview:self.HUD];
I forgot to remove it from the super view in its delegate method:
- (void)hudWasHidden:(MBProgressHUD *)hud
{
// Remove HUD from screen when the HUD was hidded
[HUD removeFromSuperview]; // app crashes at 4.59 MB if you comment this
[HUD release];
HUD = nil;
}
Because of this several views were added every time on one UIView ... I guess there is an upper limit for the number of child subviews on top of each UIView .... apple should mention this in their documentation ...
If you're not using ARC, you have for sure a leak every time you assign the property:
self.HUD = [[MBProgressHUD alloc] initWithView:view] ;
Change your code in this way:
MBProgressHUD *progressHUD = [[MBProgressHUD alloc] initWithView:view] ;
self.HUD = progressHUD;
[progressHUD release];
In my applicayion i am using a uiimageview ,and it will load diffrent images on a button click. But there is memory leak when i load images, is that needed to release uiimageview.image property before i load another image to it. Any help please...........
code for loading images to uiimageview
-(void)setOverlayImage:(UIImage *)img
{
overlayView.image=nil;
overlayView.image=img;
}
Before i do overlayView.image=img; i hope the memory allocated for the previous image will be replaced with the new image.
Or is that needed to do [overlayView.image release] and then overlayView.image=img;???????
But when i tried to release, the app crashed.
-(void)setOverlayImage:(UIImage *)img
{
overlayView.image=img;
}
This should be sufficient but you can also go for this.
-(void)setOverlayImage:(UIImage *)img
{
if(overlayView)
{
[overlayView release];
overlayView = nil;
}
overlayView = [[UIImageView alloc] initWithImage:img];
overlayView.frame = yourFrame;
// Add this to your parent view
[self.view addSubview:overlayView];
}
Hope this helps
Using ASIHTTP, the code below is in the ImageDownloader class. I get a memory leak, which is added at the bottom, but I don't know why. I thought tempImage would be autoreleased without me doing anything?
- (void)requestFinished:(ASIHTTPRequest *)request
{
UIImage *tempImage = [UIImage imageWithData:[request responseData]];
if (tempImage.size.width > 250.0f && tempImage.size.height > 180.0f)
{
self.image = tempImage;
self.circleImage = [UIImage imageNamed:#"hover.png"];
if ([self.delegate respondsToSelector:#selector(addImageToModel:)])
[self.delegate addImageToModel:self];
}
else
{
if ([self.delegate respondsToSelector:#selector(badImage)])
[self.delegate badImage];
}
tempImage = nil;
}
self.image is getting set to tempImage, so it probably retains the image. Is it released anywhere?
You should not write this line :
tempImage = nil;
Since tempImage is a function scope variable, it will be taking care of by itself.
Further more, if self.image is (nonatomic, assign) that could be the origine of your leak.
About the stack trace image, is this from leak instruments, or memory instruments ?
Unfortunately, until you give away some more code, we won't be able to help you further.
As Thomas mentioned, it may be self.image retaining the image?
Have you considered waking up the zombies ? ;)
http://www.mikeash.com/pyblog/friday-qa-2011-05-20-the-inner-life-of-zombies.html
http://www.cocoadev.com/index.pl?NSZombieEnabled
This appears to be the the classic method for scanning images from the iPhone. I have a thread that is dispatched from the main thread to go and scan for Codes. It essentially creates a new UIImage each time then removes it.
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
{
while (![thread isCancelled]) {
#ifdef DEBUG
NSLog(#"Decoding Loop");
#endif
// [self performSelectorOnMainThread:#selector(updateImageBuffer) withObject:nil waitUntilDone:YES];
CGImageRef cgScreen = UIGetScreenImage();
UIImage *uiimage = [UIImage imageWithCGImage:cgScreen];
if (uiimage){
CGSize size = [uiimage size];
CGRect cropRect = CGRectMake(0.0, 80.0, size.width, 360); // Crop to centre of the screen - makes it more robust
#ifdef DEBUG
NSLog(#"picked image size = (%f, %f)", size.width, size.height);
#endif
[decoder decodeImage:uiimage cropRect:cropRect];
}
[uiimage release];
CGImageRelease(cgScreen);
}
}
[pool release];
the problem is that the [pool release] causes an ERROR_BAD_EXC (that old classic) and the program bombs. I'm told that there is no need to call [uiimage release] as I havent explicitly allocated a UIImage but this doesn't seem to be the case. If I take that line out, Memory usage goes through the roof and the program quits dues to lack of memory. It appears I can't have this work the way I'd like.
Is there a way to create a UIImage "in-place"? I.e, have a buffer that is written to again and again as a UIImage? I suspect that would work?
Update!
Tried executing the UIKit related calls on the main thread as follows:
-(void)performDecode:(id)arg{
// Perform the decoding in a seperate thread. This should, in theory, bounce back with a
// decoded or not decoded message. We can quit at the end of this thread.
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
{
while (![thread isCancelled]) {
#ifdef DEBUG
NSLog(#"Decoding Loop");
#endif
[self performSelectorOnMainThread:#selector(updateImageBuffer) withObject:nil waitUntilDone:YES];
if (uiimage){
CGSize size = [uiimage size];
CGRect cropRect = CGRectMake(0.0, 80.0, 320, 360); // Crop to centre of the screen - makes it more robust
#ifdef DEBUG
NSLog(#"picked image size = (%f, %f)", size.width, size.height);
#endif
[decoder decodeImage:uiimage cropRect:cropRect];
}
}
}
[pool drain];
#ifdef DEBUG
NSLog(#"finished decoding.");
#endif
}
-(void) updateImageBuffer {
CGImageRef cgScreen = UIGetScreenImage();
uiimage = [UIImage imageWithCGImage:cgScreen];
//[uiimage release];
CGImageRelease(cgScreen);
}
No joy however as EXC_BAD_ACCESS rears its ugly head when one wishes to grab the "Size" of the UIImage
As has been stated by others, you should not release the UIImage returned from imageWithCGImage: . It is autoreleased. When your pool drains, it tries sending a release message to your already-released image objects, leading to your crash.
The reason why your memory usage keeps climbing is that you only drain the autorelease pool outside of the loop. Your autoreleased objects keep accumulating inside of the loop. (By the way, you need to release your autorelease pool at the end of that method, because it is currently being leaked.) To prevent this accumulation, you could drain the pool at regular intervals within the loop.
However, I'd suggest switching to doing [[UIImage alloc] initWithCGImage:cgScreen] and then releasing the image when done. I try to avoid using autoreleased objects whereever I can within iPhone applications in order to have tighter control over memory usage and overall better performance.
UIGetScreenImage() is private and undocumented so you flat-out cannot use it. Saying that nothing about it suggests that you now own CGImageRef cgScreen so why do you release it? You also have no way of knowing if it is thread safe and so should assume it isn't. You then go on to release the IImage *uiimage which you did not init, retain or copy, so again - you don't own it. Review the docs.
[uiimage release] is definitely wrong in this context. Also, Apple stresses that all UIKit methods must be executed on the main thread. That includes UIGetScreenImage() and +[UIImage imageWithCGImage:].
Edit: So you get an exception when calling -[UIImage size] on the wrong thread. This probably shouldn't surprise you because it is not permitted.
UIImage *uiimage = [[UIImage alloc] initWithCGImage: cgScreen];
Explicitly stating that I know best when to release the object seemed to work. Virtual Memory still increases but physical now stays constant. Thanks for pointing out the UIKit Thread Safe issues though. That is a point I'd missed but seems not affect the running at this point.
Also, I should point out, Red Laser and Quickmark both use this method of scanning camera information ;)
I have a UIScrollView that has a set of images loaded side-by-side inside it. You can see an example of my app here: http://www.42restaurants.com. My problem comes in with memory usage. I want to lazy load the images as they are about to appear on the screen and unload images that aren't on screen. As you can see in the code I work out at a minimum which image I need to load and then assign the loading portion to an NSOperation and place it on an NSOperationQueue. Everything works great apart from a jerky scrolling experience.
I don't know if anyone has any ideas as to how I can make this even more optimized, so that the loading time of each image is minimized or so that the scrolling is less jerky.
- (void)scrollViewDidScroll:(UIScrollView *)scrollView{
[self manageThumbs];
}
- (void) manageThumbs{
int centerIndex = [self centerThumbIndex];
if(lastCenterIndex == centerIndex){
return;
}
if(centerIndex >= totalThumbs){
return;
}
NSRange unloadRange;
NSRange loadRange;
int totalChange = lastCenterIndex - centerIndex;
if(totalChange > 0){ //scrolling backwards
loadRange.length = fabsf(totalChange);
loadRange.location = centerIndex - 5;
unloadRange.length = fabsf(totalChange);
unloadRange.location = centerIndex + 6;
}else if(totalChange < 0){ //scrolling forwards
unloadRange.length = fabsf(totalChange);
unloadRange.location = centerIndex - 6;
loadRange.length = fabsf(totalChange);
loadRange.location = centerIndex + 5;
}
[self unloadImages:unloadRange];
[self loadImages:loadRange];
lastCenterIndex = centerIndex;
return;
}
- (void) unloadImages:(NSRange)range{
UIScrollView *scrollView = (UIScrollView *)[[self.view subviews] objectAtIndex:0];
for(int i = 0; i < range.length && range.location + i < [scrollView.subviews count]; i++){
UIView *subview = [scrollView.subviews objectAtIndex:(range.location + i)];
if(subview != nil && [subview isKindOfClass:[ThumbnailView class]]){
ThumbnailView *thumbView = (ThumbnailView *)subview;
if(thumbView.loaded){
UnloadImageOperation *unloadOperation = [[UnloadImageOperation alloc] initWithOperableImage:thumbView];
[queue addOperation:unloadOperation];
[unloadOperation release];
}
}
}
}
- (void) loadImages:(NSRange)range{
UIScrollView *scrollView = (UIScrollView *)[[self.view subviews] objectAtIndex:0];
for(int i = 0; i < range.length && range.location + i < [scrollView.subviews count]; i++){
UIView *subview = [scrollView.subviews objectAtIndex:(range.location + i)];
if(subview != nil && [subview isKindOfClass:[ThumbnailView class]]){
ThumbnailView *thumbView = (ThumbnailView *)subview;
if(!thumbView.loaded){
LoadImageOperation *loadOperation = [[LoadImageOperation alloc] initWithOperableImage:thumbView];
[queue addOperation:loadOperation];
[loadOperation release];
}
}
}
}
EDIT:
Thanks for the really great responses. Here is my NSOperation code and ThumbnailView code. I tried a couple of things over the weekend but I only managed to improve performance by suspending the operation queue during scrolling and resuming it when scrolling is finished.
Here are my code snippets:
//In the init method
queue = [[NSOperationQueue alloc] init];
[queue setMaxConcurrentOperationCount:4];
//In the thumbnail view the loadImage and unloadImage methods
- (void) loadImage{
if(!loaded){
NSString *filename = [NSString stringWithFormat:#"%03d-cover-front", recipe.identifier, recipe.identifier];
NSString *directory = [NSString stringWithFormat:#"RestaurantContent/%03d", recipe.identifier];
NSString *path = [[NSBundle mainBundle] pathForResource:filename ofType:#"png" inDirectory:directory];
UIImage *image = [UIImage imageWithContentsOfFile:path];
imageView = [[ImageView alloc] initWithImage:image andFrame:CGRectMake(0.0f, 0.0f, 176.0f, 262.0f)];
[self addSubview:imageView];
[self sendSubviewToBack:imageView];
[imageView release];
loaded = YES;
}
}
- (void) unloadImage{
if(loaded){
[imageView removeFromSuperview];
imageView = nil;
loaded = NO;
}
}
Then my load and unload operations:
- (id) initWithOperableImage:(id<OperableImage>) anOperableImage{
self = [super init];
if (self != nil) {
self.image = anOperableImage;
}
return self;
}
//This is the main method in the load image operation
- (void)main {
[image loadImage];
}
//This is the main method in the unload image operation
- (void)main {
[image unloadImage];
}
I'm a little puzzled by the "jerky" scrolling. Since NSOperationQueue runs operations on separate thread(s) I'd have expected at worst you might see empty UIImageViews showing up on the screen.
First and foremost I'd be looking for things that are impacting the processor significantly as NSOperation alone should not interfere with the main thread. Secondly I'd be looking for details surrounding the NSOperation setup and execution that might be causing locking and syncing issues which could interrupt the main thread and therefore impact scrolling.
A few items to consider:
Try loading your ThumbnailView's with a single image at the start and disabling the NSOperation queuing (just skip everything following the "if loaded" check. This will give you an immediate idea whether the NSOperation code is impacting performance.
Keep in mind that -scrollViewDidScroll: can occur many times during the course of a single scroll action. Depending on how for the scroll moves and how your -centerThumbIndex is implemented you might be attempting to queue the same actions multiple times. If you've accounted for this in your -initWithOperableImage or -loaded then its possible you code here is causing sync/lock issues (see 3 below). You should track whether an NSOperation has been initiated using an "atomic" property on the ThumbnailView instance. Prevent queuing another operation if that property is set and only unset that property (along with loaded) at the end of the NSOperation processes.
Since NSOperationQueue operates in its own thread(s) make sure that none of your code executing within the NSOperation is syncing or locking to the main thread. This would eliminate all of the advantages of using the NSOperationQueue.
Make sure your "unload" operation has a lower priority than your "load" operation, since the priority is the user experience first, memory conservation second.
Make sure you keep enough thumbnails for at least a page or two forward and back so that if NSOperationQueue falls behind, you have a high margin of error before blank thumbnails become visible.
Make sure your load operation is only loading a "pre-scaled" thumbnail and not loading a full size image and rescaling or processing. This would be a lot of extra overhead in the middle of a scrolling action. Go even further and make sure you've converted them to PNG16 without an alpha channel. This will give at least a (4:1) reduction in size with hopefully no detectable change in the visual image. Also consider using PVRTC format images which will take the size down even further (8:1 reduction). This will greatly reduced the time it takes to read the images from "disk".
I apologize if any of this doesn't make sense. I don't see any issues with the code you've posted and problems are more likely to be occurring in your NSOperation or ThumbnailView class implementations. Without reviewing that code, I may not be describing the conditions effectively.
I would recommend posting your NSOperation code for loading and unloading and at least enough of the ThumbnailView to understand how it interacts with the NSOperation instances.
Hope this helped to some degree,
Barney
One option, although less visually pleasing, is to only load images when the scrolling stops.
Set a flag to disable image loading in:
-scrollViewWillBeginDragging:
Re-enable loading images when the scrolling stops using the:
-scrollViewDidEndDragging:willDecelerate:
UIScrollViewDelegate method. When the willDecelerate: parameter is NO, the movement has stopped.
the problem is here:
UIImage *image = [UIImage imageWithContentsOfFile:path];
It seems that threaded or not when you load a file from disk (which maybe that happens on the main thread regardless, I'm not totally sure) everything stalls. You normally don't see this in other situations because you don't have such a large area moving if any at all.
While researching this problem, I found two more resources that may be of interest:
Check out the iPhone sample project "PageControl": http://developer.apple.com/iphone/library/samplecode/PageControl/index.html
It lazy loads view controllers in a UIScrollView.
and -
Check out the cocoa touch lib: http://github.com/facebook/three20 which has a 'TTPhotoViewController' class that lazy loads photos/thumbnails from web/disk.
Set shouldRasterize = YES for the sub content view adde to the scrollview. It is seen to remove the jerky behavior of custom created scroll view like a charm. :)
Also do some profiling using the instruments in the Xcode. Go through the tutorials created for profiling by Ray Wenderlich it helped me a lot.