I'm a newbie trying to figure out a memory leak problem. Does anyone see anything wrong with the following code?
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self.navigationController.navigationBar setTintColor:[UIColor colorWithRed:0.10 green:.20 blue:0.30 alpha:1]];
}
In case it helps, Instruments shows the leaked block with the following info...
Event Type: Malloc
Responsible Library: CoreGraphics
Responsible Caller: CGTypeCreateInstanceWithAllocator
Any help would be greatly appreciated. (I'm still very new, so please explain in as much detail as possible.)
Much thanks!
Bit of a long shot but I'm not sure if it was just a bug in my project or not but I had a similar issue once when setting tintColor in viewWillAppear. I ended up adding an nil check before assigning the color again and this cleared it up for me (I didn't do any further investigation into it so I could be wrong).
if (nil == self.navigationController.navigationBar.tintColor) {
self.navigationController.navigationBar = [UIColor colorWithRed:0.10 green:.20 blue:0.30 alpha:1];
}
The code you have posted is correct, as far as memory management is concerned.
Instruments Leaks will simply show the point where the leaked object is allocated, not the point where it is actually leaked.
So, your leak is elsewhere. Looking at your code, I would say that the leak is possibly occurring when you release the class containing that code, or elsewhere along the dynamical path to dealloc.
Try commenting out setTintColor to check whether the leak is still there.
Hope this explanation can put you on the right track, but in any case, if you need more help, you should post more code...
Related
I'm writing a networking program which sends an image from an iPhone to a Mac. I have the connection going fine, and passing data alright, but my problem is when I have the image sent over I try to display it and get the following warning:
NSImageView(0x101321fd0) - NSView not correctly initialized. Did you
forget to call super?
Here is the code, it's the "setImage" command throwing the error.
This is my first major venture into Objective-C, I'm worried I messed up something with the xib but I can't be sure.
imageView = [NSImageView alloc];
[imageView setImage:theImage];
NSLog(#"Should be able to see image now..");
If this is too vague for a direct answer then any tips, references or tutorials you can guide me to would be very welcome.
Thanks for your time.
You forget to init the imageView.
imageView = [[NSImageView alloc] initWithFrame:someFrame]
I have done navigation one viewcontroller to another, But when I done navigation multiple times my application shows memory leak, I run application with NSZombie detection ,that shows "Insufficient task_for_pid privileges (LeakAgent)". It is ARC enabled(xcode 4.2, iOS5) Please help.......
My code is here:
self.locationMapDetail = [[LocationMapDetail alloc] init]; //14.3% Leak
self.locationMapDetail.objItem = [self.parsedItems objectAtIndex:selectedIndex]; //5.7% Leak
[self.navigationController pushViewController:locationMapDetail animated:YES]; //80.3% Leak
self.locationMapDetail = nil;
self.locationMapDetail.objItem = nil;
You must release the objects before making it nil.Something like
[self.locationMapDetail release];
self.locationMapDetail = nil;
You should do it for all the objects that you allocate , if you are not using ARC.
In case of strong pointers even if you release the object you might not release it efficiently or it may be only virtually released as a strong pointer can be released only if all the references of the strong pointer has been released.It happens because sometimes the target may have strong pointer reference back to the declared variable.
Also Please mention the method you are using to create your variables..(viewDidLoad or viewWillAppear).It is advisable to create it in viewDidLoad.
I have also faced the same issue, It took me almost 2 days to resolve the issue. Finally got the solution.
Make sure that your profile scheme is in DEBUG mode instead of RELEASE. This will solve the issue.
I am getting a crash the second time I attempt to add a certain view as a subview. The crash happens here:
-(void)AddAsScrollableSubContext:(UIView*)view {
[pExtendedScrollableSubContextBounds addSubview: view]; //CRASH HERE
pSubScroll.userInteractionEnabled = true;
}
the second time I call...
[mSongContext AddAsScrollableSubContext:pEQRoot];
The flow is something along the lines of
[mSongContext AddAsScrollableSubContext:pEQRoot];
...Load a lot of stuff
...Press a Button
...Unload a lot of stuff
[pEQRoot removeFromSuperview];
...Press a Button
[mSongContext AddAsScrollableSubContext:pEQRoot];
When I get the bad access the callstack looks like the following:
Both objects (pExtendedScrollableSubContextBounds and pEQRoot) appear to be valid. Adding other subview to pExtendedScrollableSubContextBounds works fine and calling other operations on pEQRoot (subview, frame) also work.
I read the in objsend r0 was the object and r1 was the selector so I looked at the memory address for r1 and saw...
This feels like I am trashing memory somewhere around isKindOfClass: but I am not quite sure. Could anyone point me to more info on iOS obj_msgsend? is there a way I can setup a watch point to catch when this memory trash is occurring?
Use NSZombies to fix the problem.
On a slightly unrelated note, there's a rule of thumb - NARC which stands for new, allocate, retain, copy. If a method call includes any of these keywords, then we have ownership of the object and we are then supposed to release the object.
I'm using the leaks tool in XCode's instruments to find memory leaks (go figure). I have a few leaks each time I run my app at different points in the app. I look at the extended details, and I'm never pointed to any of the code I wrote, only code built into the foundation of xcode. Two examples of this are:
http://imageshack.us/photo/my-images/192/screenshot20110728at102.png/
http://imageshack.us/photo/my-images/853/screenshot20110728at102.png/
As you can see, some of the problems come from the Message UI library. The only place I use that is here:
-(void)displayComposerSheet
{
MFMailComposeViewController *mail = [[MFMailComposeViewController alloc] init];
mail.mailComposeDelegate = self;
[mail setSubject:#"Suggestions"];
[mail setToRecipients:[NSArray arrayWithObjects:#"sampleEmail#gmail.com", nil]];
[self presentModalViewController:mail animated:YES];
[mail release];
}
-(void)launchMailAppOnDevice
{
NSString *recepient = [NSString stringWithFormat:#"mailto:sampleEmail#gmail.com"];
recepient = [recepient stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:recepient]];
}
-(void)mailComposeController:(MFMailComposeViewController *)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError *)error
{
[self dismissModalViewControllerAnimated:YES];
}
How can I fix this? Thanks!
Finding out where a leak comes from is not always an easy task, helping remotely is even more complex.
In your case, what could help is the little arrow that is shown next to the memory address of the leak. If you click on it, you should get shown an information pane with the full stack trace at that moment. Inspect the list of methods presented there and look for some method of yours, then click on it to inspect the code.
There is not much else you can do in Instruments that get an idea about where the leaked object was created. You should then figure out where you could have missed releasing it.
As to Apple SDK, there are a few memory leaks that are reported and that you can find out there on the web, but they are really seldom.
If Instruments does not help you, one important consideration for you is: what was your app doing when Instruments reported the leak? Retrieving data from the web, displaying a new view, whatever... this could help in delimiting the field of your further investigation. If the leaks shows up multiple times, this could also be a great value to identify what part of your program could be producing it.
If you get a clue about that, then go check the code that accomplishes that. One technique (I know that it might sound strange, but try it) is removing/commenting out chunks of code and then checking to see whether the leak is still there.
"Removing/commenting out chunks of code" may mean many things, from not making a web request, to avoid using a class of a type and replacing it with another. This is not always a simple process, because you impair the app functionality, so you have to use your knowledge about how remove functionality and leave your app "testable". If you are lucky, this could help you further delimiting the code that is causing the leak.
Keep in mind that also the static analysis tool could help, and that leaks is not perfect, sometimes it is wrong. There is another technique to discover leaks that is not based on Leaks, but on Object Allocation. This is very powerful in my experience and I strongly encourage you to try that also, although I suspect that it will not help in this case. It is called heapshot analysis.
Quick one folks. Have a quick look at the code snippet below. I alloc the UILabel *textLabel but I don't release it (commented out). When the method ends, I lose reference to the pointer so it leaks.
Thing is that XCode Instruments doesn't find this leak and I would have thought that it is quite a straightforward case for it to find it. Its not reporting any leaks in my application and yet I found this one myself and its made me a little suspicious.
Am I over looking something or is Instruments rather poor at detecting leaks?
-(UITableViewCell*)newReadOnlyCellWithTitle:(NSString*)title andText:(NSString*)text {
UITableViewCell *cell=[[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:nil] autorelease];
cell.textLabel.text=title;
cell.selectionStyle=UITableViewCellSelectionStyleNone;
cell.backgroundColor=[UIColor whiteColor];
cell.opaque=YES;
UILabel *textLabel=[[UILabel alloc] initWithFrame:CGRectMake(80, 11, 350, 24)];
textLabel.text=text;
textLabel.textColor=[UIColor lightTextColor];
textLabel.font=[UIFont fontWithName:STANDARD_FONT size:16.0];
textLabel.opaque=YES;
textLabel.backgroundColor=[UIColor clearColor];
[cell.contentView addSubview:textLabel];
//[textLabel release]; //<== without the release this should leak, yep?
return cell;
}
Edit: output from static analyizer...
Instrument's leak detection works by conservatively scanning memory, looking for pointers and building a graph of connections between allocations. If it finds any pointer(s) to an object in memory that can be reached from a global variable or stack variable, then that object cannot be considered leaked.
Instruments does not know the layout or context of a pointer. If you were to malloc(1024) and there happened to be a bunch of pointers in that [recycled] chunk of memory, those would count even though you will never treat those pointers as real references again.
So, no, Leaks can never be 100% accurate. As well, there are far more many ways to leak memory than an actual leak. If you had a global cache, like this:
NSMutableDictionary *myGlobalCache;
And you were to fill that cache but never prune it, that would be an effective memory leak and there is no way that it'll every show up in Instruments.
I wrote up an in depth discussion of Heapshot analysis, which is related and may be of interest.
Let me guess, -newReadOnlyCellWithTitle:andText: gets called by your -tableView:cellForRowAtIndexPath: method when cell == nil?
The thing is, those cells don't get released, they are cached and pulled back by -dequeueReusableCellWithIdentifier:. Table view uses same cells over and over again thus reducing the need to constantly allocate and release memory.
To make sure this is the case, you can try switching to different view controller, then simulating memory warning in simulator. This will force release on previous controller's view and as a result on cells in discussion. You should notice a leak in Instruments.
I think u will see it only when there are no valid references.
So, in your case, there is still a valid reference that goes something like, (probably) Screen -> table -> cell -> label. Looks like there is a possibility that your screen, the primary view, is still in memory, and hence still a valid reference.
You might want to check the objects that are allocated and then not released and still stay in the memory as valid objects. Checking for leaks isn't always enough.
Leaks will only find objects that are not referred to by any other object. For example if you create two objects in a method that refer to each other but no one else refers to either of them they are both technically leaked objects but leaks can see them since they each have an object that refers to them. Static analyzer is pretty good at finding these kinds of things though so the two in concert should kill almost any leak.
Your missing that there are 2 pointers to the object
Locally you have
UILabel *textLabel=[[UILabel alloc] initWithFrame:CGRectMake(80, 11, 350, 24)];
And within the windowing system which will manage it for you (it is my understanding it is not making a copy, but taking ownership)
[cell.contentView addSubview:textLabel];
So release is unnecessary, and with my limited knowledge even bad.
//[textLabel release]; //<== without the release this should leak, yep?