Instruments show me a leak in simulator in the following code,
UIBarButtonItem *connectButton = [[UIBarButtonItem alloc] initWithTitle:#"Connexion" style:UIBarButtonItemStyleBordered target:self action:#selector(pushViewController)];
[self.navigationItem setLeftBarButtonItem:connectButton animated:animated];
[connectButton release];
Do you see any leak ?? thanks
Leaks is showing you where the object was allocated, not where the object was leaked.
While the two might be the same, it is often much more likely that the leak of an object is caused by an extra retain or missing release somewhere else.
I don't see any leaks in the code you posted. That said, a couple questions:
How do you know that's where the leak is?
Any chance the getter for navigationItem is using copy? If so, there could be a leak there.
...and on device? You should check this on device. There are very, very few situations where you'd want to use the simulator for this kind of testing. It's not representative of how the device itself behaves. I'd recommend you test this on a device, and then if you're still seeing it come back here.
Related
i have found leaks in the below code at particular area, means when i push my view from other sides, There is not any leak i found but only this push give me 100%leak.
actionsListing *View = [[actionsListing alloc] init];
[self.navigationController pushViewController:View animated:YES];
[View release];
What will i do thanks.
That code is fine - you're doing everything correctly.
Are you testing in the simulator or on a device? If it's the simualtor, don't. The simulator has a different memory model and reports leaks that aren't really there; always test for leaks on a device :)
If you still get leaks, you're retaining the view controller somewhere else by mistake - that code is definitely correct.
Dear all, I have a navigation-based app with about 60 UIControllerViews, which is divided into 4 sections.
I have run with the following : 1. Build and analyse : bulid is successful with no complains. 2. Instruments allocation and leaks : no leaks.
However, the app crashed in iPhone or iPad but works fine in simulator. There is no crash reports but I do see LowMemory.log in the crashreporter folder.
I have upgraded my iphone and ipad to 4.2
Does anyone have ideas what could be wrong? I have been reading and troubleshooting for a week.
Is there a need to remove/release the UIControllerViews?
The app crashes simply by navigating between the views.
Thank you for any help.
My app has a root view called contentViewController and users can navigate to 4 quizzes from here.
This is the code I use to return to my root view.
- (void)goHome {
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle: #"Warning"
message: #"Proceed?"
delegate: self
cancelButtonTitle:#"Yes"
otherButtonTitles:#"No",nil];
[alert show];
[alert release];
}
- (void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex {
[[self navigationController] setNavigationBarHidden:NO animated:YES];
if (buttonIndex == 0) {
NSArray * subviews = [self.view subviews];
[subviews makeObjectsPerformSelector:#selector(removeFromSuperview)];
self.view = nil;
if (self.contentViewController == nil)
{
ContentViewController *aViewController = [[ContentViewController alloc]
initWithNibName:#"ContentViewController" bundle:[NSBundle mainBundle]];
self.contentViewController = aViewController;
[aViewController release];
}
[self.navigationController pushViewController:self.contentViewController animated:YES];
}
else {
}
}
The simulator isn't going to give you any useful information about memory warnings—your app, running there, effectively has access to all the memory the system's willing to give it. The device is where you need to be testing for memory usage, and if you're getting warnings and crashes, then you need to do some Instruments work to figure out where you can free up some of that memory.
Look at your xcode console. If you are getting a number of low memory warnings, then you need to be allocating and de-allocating your views on the fly because they are taking up too much memory on the device (the simulator isn't quite so memory restricted).
But it could be about a million other things causing your crash. Make sure you're doing a debug build (breakpoints on) so the debugger will kick in and hopefully you can see where on the stack your crash is occurring.
You have some good suggestions already. However I'd suggest spending a lot of time reviewing XCode's debugging tools documentation. This so you have a basic understanding of what they are capable of and how to use them. Follow that up with some reading on iOS memory management, auto release pools and the like.
For your app you need to realize that there is no swap space on iOS devices. So you are forced to manage memory to an extent that you mat not have to on other platforms. Generally that means you don't want to keep to much view data in memory if it can be avoided.
In the case of the current iPad there may only be about 110MB of RAM available to the app. Specific numbers probably are iOS version dependent. In any event you need to get an idea as to how large the data structures (in memory) are for your various views. 60 different views could be considered a lot depending upon memory usage, if you don't manage it correctly you are likely to run out very quickly. This not like programming in Java or other garbage collected language.
Lastly; even though this sounds like a memory management issue it could always be something else. If you still have trouble you will need to post code. Right now it is really guess work on our part. Just remember you do not have VM and there is no garbage collection.
You are using up memory, always remember if you allocate memory you must release it, in some cases you can use autorelease so you dont forget to release it after the void dealloc method before end.
I'm experiencing a wierd behavior in the new AVFoundation classes in the iPhone SDK.
I have a AVCaptureStillImageOutput for taking pictures, and I am setting its outputSettings to my liking. The code follows:
AVCaptureStillImageOutput *stillImageOutput = [[[AVCaptureStillImageOutput alloc] init] autorelease];
[stillImageOutput setOutputSettings:[NSDictionary dictionaryWithObject:AVVideoCodecJPEG forKey:AVVideoCodecKey]];
[self setStillImageOutput:stillImageOutput];
(stillImageOutput property is defined as "retain")
I stumbled upon a leak in leaks, with 100% of the leak fault on the setOutputSettings line. I believe that I confine to the memory management guidelines in the code attached, still it is leaking.
My solution was to
[self.stillImageOutput setOutputSettings:nil];
in the dealloc, just before
[self setStillImageOutput:nil];
The leak indeed stopped, but it looks weird. Shouldn't the releasing of stillImageOutput release its outputSettings property as well?
Anyway, if someone else runs into this, thought I should share my solution.
Cheers!
Oded.
Yes, the releasing of stillImageOutput should release it's outputSettings property as well. Either it's an Apple bug (should let them know, your use case is pretty simple) or remove your line, and see whether anything other than your class is hanging onto that stillImageOutput object (which is holding the outputSettings).
The Leaks instrument tells me that I have a leak in this code fragment. Why is this so?
This code fragment is in viewDidLoad().
UINavigationItem *navItem=[self navigationItem];
UIBarButtonItem *addFeed = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAdd target:self action:#selector(addFeed)];
[navItem setRightBarButtonItem:addFeed]; // leaks says that 128 bytes leaked
[addFeed release];
UIBarButtonItem *reload = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemRefresh target:self action:#selector(reload)];
[navItem setLeftBarButtonItem:reload]; // leaks says that 128 bytes leaked here too !
[reload release];
[navItem release];
You should not be releasing navItem. You did not alloc/retain/new/create it, so you do not release it.
Other than that, your code looks fine. Is that everything in the method?
The leaks instrument only tells you where the leaked memory was allocated; it can't tell you where the memory should have been released but wasn't since there's no possible way for it to know that. Your leak is occurring elsewhere.
This code is mostly fine, except you should not be releasing navItem at the end. You are not an owner of it, since you didn't create it with a method named alloc, new, or copy in its name, so you should not release it.
if you're still getting the leak message and can't track down the bug, you can try using the static analyzer included in the latest and greatest Xcode (version 3.2)
Build > Build and Analyze
it'll use LLVM-Clang to statically analyze your code in a pretty way.
http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/index.html
UPDATE:
in your code snippet:
UINavigationItem *navItem=[self navigationItem];
UIBarButtonItem *addFeed = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAdd target:self action:#selector(addFeed)];
[navItem setRightBarButtonItem:addFeed]; // leaks says that 128 bytes leaked
[addFeed release];
your leak is probably coming from setting the new rightBarButtonItem without releasing the old one.
this is what i think is happening:
1) get a handle to the navigationItem (has right bar button A)
2) create a new UIBarButton Item (making right bar button B)
3) setRightBarButtonItem to button B
now where's Button A? it should have been released by navItem when you set the new button. so you could have forgotten to release the button when you set it the first time, or you've got it retained somewhere else.
Do you have NSZombieEnabled? This causes objects not to be retained by the NSZombie instances and you'll see "leaks" when running the Leaks tool.
It seems that you're not releasing the view controller with custom viewDidLoad method.
[navItem setRightBarButtonItem:addFeed];
[navItem setLeftBarButtonItem:reload];
You are creating copies of the objects in these accessors. These accessors are incrementing the retainCount by 1. Your accessors should release each object and then immediately retain them.
Example:
- (void) setTitle: (NSString*) newTitle {
if (title != newTitle) {
[title release];
title = [newTitle retain]; // Or copy, depending on your needs.
}
Take a look at the techniques here:
Memory Management Programming
I believe that's what's up. So take a hard look at those two accessors.
I'm getting memory leak with UIImagePickerController class.
Here's how I'm using it:
UIImagePickerController *picker = [[UIImagePickerController alloc] init];
picker.delegate = self;
picker.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
[self presentModalViewController:picker animated:YES];
[picker release];
To remove the picker i call [picker dismissModalViewControllerAnimated:YES]; in didFinishPickingImage and imagePickerControllerDidCancel.
--
Instruments show around 160bytes leaking as a result of this instruction:
+[UIImagePickerController _loadPhotoLibraryIfNecessary]
Apparently this issue has and is disturbing many people, and solution
to avoid this problem is to build a
singleton class dedicated for picking
images from library or capturing using
device's build in camera.
Anyone want to add something?
As the author of one of the first articles about the necessity to use a singleton, the motivation was to prevent a crash on the 7/8th image capture, not because of any particular worry about the leak. 160 bytes is annoying, but not a major problem, and therefore not worth worrying about (because it can't be fixed by developers).
Have you tried deleting the delegate line? I’ve had similar problems with AVAudioPlayer when delegating to self. (Even though the accessor says assign in both cases.) If the leak goes away with the delegation, you can delegate to a different object.
I was having a memory alloc leak which I found in Instruments.
All I was doing was opening and closing the image picker (open/cancel) and using Apple code, my code and other people's code.
All were showing the allocation going up and up each time, as if the picker was not being released.
If you tried to release it, it would crash (over released).
Then I found a really helpful web page which basically stated:
"This doesn't happen when testing on the device"
So I switched from the simulator and ran the tests on the device.
Lo & behold there was no allocation increase and it behaved normally.
This however is totally evil and now we can place no trust in the simulator to do a reliable job. Whether this is pertinent to your specific problem or not, I took you up on anything else to add, and my thing to add is don't test memory on the simulator!
The reason maybe that you forget to release image. Because each time you write
UIImageView.image = image_a;
Then , image_a will get retained once.
Until you let UIImageView.image = nil, when image_a can be release finally.
I resolved my problem in this way.
If you see memory leaks several GeneralBlock and SegmentMachO by using UIImagePickerController,
Try by adding CoreLocation framework and MapKit framework to your project. I don't see anymore memory leaks in the instrument tool leak checking. I don't know how UIImagePickerController related to these frameworks. I am not sure it is good solution or not. "adding frameworks without using or necessary".
I have also got the memory leak by using UIImagePickerController. That memory leak happen even in the sample code "PhotoLocation" and "iPhoneCoreDataRecipes" downloaded from developer.apple.com. I also checked by adding these frameworks to those downloaded sample code. There is no memory leaks anymore.