I have a strange problem with a memory leak (the only one ;-) ) in my iPhone app:
alt text http://img253.imageshack.us/img253/8530/bildschirmfoto20091105u.png
I don't know where I have to look for the cause of this leak... the strange thing is that this, exactly this leak also shows up if I create a new navigation-based app and just run it without any changes. I'm testing it in the simulator BTW because I don't have my developer certificate until now.
Has anybody an idea what could be the cause of this leak?
Apple is not perfect and sometimes has leaks in the code. If all your app is leaking is 256 BYTES then I think you will just be wasting your time trying to track it down. My advice is to forget about it.
Related
I created a test project to confirm my memory leaks:
Project file: https://dl.dropbox.com/u/3703182/PickerView.zip
Basically a UIPickerView is connected to a datasource via IB. When it's connected to a datasource, it leaks. If not, no leak. I need to use a UIPickerView for an imminent app that needs to be released ASAP, unfortunately it guarantees a crash every 2 hours because of the leak. How can I use the UIPickerView despite the memory leaks without crashing?
EDIT:
It only leaks on device, not in simulator.
That is not a leak. It's an allocation.
If it was a leak it would show a red spike in the second row.
The real test for a leak is presenting and dismissing several times over. If you can do that and show that the allocations keep rising then there is a leak. Not otherwise.
Adding my comments as answer,
Your app will not crash due to this leak since it is a very small leak caused by framework which you dont have to worry about. The screenshot shows that it is in terms of a few bytes. If your app is crashing every 2 hours, that means there is something else which is using a lot of memory. Please check if you are using anything else in your code which could cause this and update the question with your finding.
In allocation tool, make sure you are checking the live bytes section and check how much it is going up. If it stays below 15-20 MB, you dont have to worry much anyways. Check this for more details about memory usage in app. Also check this XCode Instruments Allocations: Look at Live Bytes or Overall Bytes?.
This is the Apple library that is leaking. You cannot do anything about this. It is Apple's fault.
This isn't a leak you can control, it's internal... but this is a very small amount of memory and will not crash your application. I'd be interested in seeing what this looks like an hour in... Can you provide a backtrace of the crash? That would probably better help determine the real cause of the crash.
I have a working iPhone app using SDK 4.0. It shows no leaks in the 'Instruments' tool, and I am fairly convinced that the code does not have any memory leaks.
I then tried to add iAds to the app, and it started showing memory leaks. In order to nail down the problem, I removed all additional code.
All that is left is an added AdBannerView to the .xib file (without doing a single modification to the working version of the code without iAds). This shows memory leaks.
Every time the view loads, the 'Instruments' tool shows 5 leaked blocks of 16 bytes each, with the Responsible Library 'Foundation', and Responsible frame
[NSCFString copywithZone:]
Further running the app gives me leaks from the Responsible library 'iAd' (2 leaks of 48 bytes each), and the responsible frame:
[AdBrandingFrame initWithFrame:]
Further, I also get 48 byte leaks with the responsible library 'UIKit' and responsible frame
-[UIView _createLayerWithFrame:]
Since there is absolutely no addition to my working non-leaking code, except an added AdBannerView to the .xib file, I wonder if it is Apple's code that causes the leak. Although the leak is relatively small, I would like to iron it out. I understand that there is a possibility that a leak shows up even though there may not be one (the pointers might still be held by the OS in some way that Leaks does not know about - It would be great to know if this is the case).
So I had two questions:
1) Is there any chance the problem is actually my code, and the leak for some reason only shows up after adding AdBannerView? If there is such a possibility, I would run another thorough code test.
2) If this is a problem with Apple's code and any of you have encountered this, are there any workarounds you have found?
Any help would be greatly appreciated. Thanks!
I just had the same issue. I think this has been fixed in IOS 4.1
When I test in 4.0 I got a couple leaks "NSCFString copyWithZone"
When testing in 4.1 all is good.
I've developed my application using my 3G device to test with. Upon giving this to a friend to test, he's noticed that it crashes..I've had a look at the crash log, but it's not much use except for the "EXC_BAD_ACCESS" statement after a few memory warnings.
On my device, I can use the imagePicker lots, and each time a photo is taken I get a memory warning, but this doesn't cause any problems.
On my friend's device (also a 3G), after a couple of images chosen from the camera, the app crashes.
So, my question is.. I think something is being deallocated because of the memory warning - but only on my friend's device, and then after deallocation, it's trying to be used again. How can I find out what object is being called? I can't use NSZombies because this is a remote (beta) device.
Help please!
Also if anyone has any ideas why my device can pick image after image without any problem and his can't...that would be most helpful
Thanks!
EDIT: New discovery.. I'm getting this error message too: KERN_PROTECTION_FAILURE which I understand to be something to do with data access. The crash seems to happen right after I save the image got from the UIImagePicker. Any ideas?
You may be over-releasing something. If you're running Snow Leopard, run the Static Analyzer (Cmd-Shift-A) and look for memory errors.
The fact that it crashes after a memory error suggests that a UIViewController has released its view. Do you have any UIViewControllers that observe NSNotifications, or otherwise might change their IBOutlets while they are off-screen? This is a common cause of this kind of crash. Make sure you're correctly memory managing your IBOutlets. UIViewControllers should never mess with their IBOutlets (or their UI components at all) when they are off screen. Even if you don't make this mistake, if you're not implementing things as noted in the above link, you can still crash after memory warnings.
MemoryWarning was a pretty good idea, and things have improved, but Apple still hasn't quite cooked all the issues around how it plays with UIViewController. The developer still needs to be very careful.
You should have your friend come to your computer and run it with NSZombieEnabled. That's the best way to debug these issues.
i'm only create an project with a Utility Application template.
This template has a native memory leak when i push "info button" to
flip the view.
Anyone know how can i fix this leak ???
I just make an new project from this template,
i don't add new objects.
That might be a leak or it might not be a leak. If you were to add the backtrace of the allocation, that would be helpful.
More likely than not, it isn't a leak, but some bookkeeping information that is being stashed away by dyld that leaks/Instruments loses track of.
Given that it is 128 bytes and I'm guessing there is only one of them, I would encourage you to file a bug via http://bugreport.apple.com and then forget about it for now as, in the unlikely case that it really is a leak, you will be equally as unlikely to be able to fix it from within your application.
Hope this helps.
From: http://www.cocos2d-iphone.org/forum/topic/2460
"The simulator has bugs related to singletons and llvm stuff that are incorrectly reported by Instruments. Always check your leaks on the device itself."
Got the leak doing this:
XCode 3.2--
File, New Project, Navigation-based Application
Give it a name
Build It
Run With Performance Tools -> Leaks
When Instruments comes up, click on Leaks (you might have to click the little icon at the bottom that looks like four boxes within a box)
About 7 seconds after running you should see the leak:
-- Malloc 128 Bytes, some Address, 128 Bytes, CoreGraphics, open_handle_to_dylib_path
I traced it to this code in the AppDelegate:
//APPLE CODE
- (void)applicationDidFinishLaunching:(UIApplication *)application {
// Override point for customization after app launch
[window addSubview:[navigationController view]];
[window makeKeyAndVisible];
}
I broke out the navigationController (did a separate alloc and release) and COMMENTED OUT the addSubview: action - there was no leak - and, obviously, the screen was blank.
It wasn't until I attempted addSubview that the leak occurred. Since there are numerous ways to add a subview, I tried those. Each resulted in the leak or a blank screen.
I tried it on a real ipod touch. No leak was reported.
Probably just a simulator thing ...
Leaks has flagged open_handle_to_dylib_path in CoreGraphics for me as well; there is definitely something flagged here. Since it is merely 256 bytes at its heaviest, I fired off a bug report to Apple and called it done. You can then set a rule in Leaks' configuration to ignore the report.
As bbum pointed out, there might be serious voodoo at work. I seriously doubt Apple would let leaky frameworks go through QA -- especially since it's so easy to reproduce.
This must be a bug. It appears in Apple's own example, PageControl, found here:
http://developer.apple.com/iphone/library/samplecode/PageControl/index.html#//apple_ref/doc/uid/DTS40007795
In the current SDK utility template is no leak. How did you get the impression there's a leak in the template? It's just allocating memory which is needed for the views.
A leak is memory to which no pointers exist and which cannot be freed any more.
I had the same problem, but was able to understand why it happened. And I have given a brief info regarding this problem in this article
Might be useful for you.
I have an app that has a tabBar Controller and a navBar Controller. It has ~8 views (a variety of web, table, standard, mail, address etc.), some created using IB some created using XCode to make the table views. I've ran the memory leak tester and it doesn't have memory leaks. It can crash at anytime on any of the views, If I flip back and forth between views and use some of the functions it closes the app.
I assume that either I am running 1) out of memory or 2) not releasing views correctly, which causes the app to close. The app is simple so I don't know how I could be out of memory and I've reviewed the code to the best of my ability for releasing the objects correctly.
So Here is my list of questions:
1) What and How to use some of the other debugging tools (or tell me what tools/files I should be looking for using)? I would like to narrow down the problem to its source.
2) What is the best practice for releasing these views? How?
3) How much memory do normal apps use? Is there a number that I should stay around? How do I verify that in the simulator? the Allocation tool?
Feel free to point me to apple docs or other stackoverflow questions that can help me.
UPDATE: It appears to only be crashing one view is used, which has a table view with custom cells... The cell are populated from a plist file... this view worked fine a few days ago, I notice that some cells do not have data from the plist file... it could be a plist file problem with not storing proper data. I'll continue to work on it.
UPDATE #2: I went back to older rev of my files, to when this particular tableView worked just fine (pre 3.0) and guess what it works just fine, I change the simulator to 3.0 with this rev of the app and bam crash on this tableView shows up. Thanks for the help so far, I'll try somethings mentioned below and let you know what I find. If you have some tips on why a tableView w/custom cells from 2.2.1 to 3.0 would start crashing, I'll take them. If I can't get anywhere I'll post the code soon. BTW, I mis-spoke above, I thought it wasn't crashing in the simulator... I was wrong it is.
Solution: thanks for the troubleshooting tips the fix was quite simple, but it's odd it didn't crash in 2.2.1... it should have crashed a long time ago for the problem, I was releasing an object one to many times in my custom cell... duh.
On the first and second generation phone's you really don't want to be going over about 20 megs of real memory usage - once you get over that you are at risk of being killed by springboard.
One of the big culprits I've seen is autoreleased memory, since the autorelease pool can hold onto memory a lot longer than you would really like - if you are using a lot of autoreleased objects that can be a potential problem. You can improve this by doing more explicit retain/release where possible and by creating local autorelease pools manually and releasing them after doing a more intensive operation with a lot of autoreleased objects.
The most effective way to keep track of real memory usage I've found so far is running a debug build on a test phone and running with Activity Monitor. That will give you a clear idea of how much memory is getting taken and held onto by your app. As well as how much is being used when it crashes on you.
You can run with Activity Monitor in Xcode on the Run menu -> Start With Performance Tool -> Activity Monitor.
One other very useful tool is the CLang Static Analyzer that you can run against your code base and can give some very helpful memory management information. As mentioned here.
One thing I would try is putting some debug messages into your didReceiveMemoryWarning method(s). That way, if you are running out of memory, you'll at least have some warning.