I have an application under development that uses a large amount of memory for images and OpenGL textures.
I have noticed that occasionally, in fact frequently on some devices, SpringBoard, the application which manages the home screen for the iPhone and iPad can take up excessive amounts of memory, sometimes twice as much as normal.
When this happens, it sends my application in to memory warnings and even crashes. My images do get released as soon as possible, but I believe that due to the sheer volume, it simply isn't good enough and still results in crashing...
I can't find much in the Apple docs about SpringBoard, but it's pissing me off.
Any ideas or pointers on figuring out what causes SpringBoard to be so aggressive?
Your application shouldn't crash in these situations -- it should shut itself down gracefully when the OS tells it to quit. Apple won't document Springboard very much because there's not much they can tell you about it that should affect what you do as a programmer, which boils down to "use as little memory as possible; don't leak memory; quit as quickly as possible when told to quit".
In short, if you're spending any more time worrying about Springboard's behaviour, instead of fixing the crashes in your app, you're not using your time wisely.
The answer was that MKAnnotationViews, despite being autoreleased, were pooling up in the memory footprint of SpringBoard, as opposed to my own app, and were not manifesting themselves very clearly in Instruments.
This is a fairly deceptive thing on Apple's part, particularly in that they allow you to autorelease and never use an object, but it will never actually be released... therefore it is technically not a leak in the eyes of Instruments and static analysis, but can still easily lead to memory related crashes.
Related
If my app uses less than 10MB do I have to bother to use those methods? I know that they are for caching low memory situations but this might occur only if you do not tested you app before releasing it. If you have tested your app, the app does not have leaks, have a small memory footprint, then why should anyone bother to use memory warning methods?
Your app is probably not the only thing running on the device. Other apps and processes are also taking up memory, and in some situations they may need it more than you. It's always a good idea to respond to memory warnings by releasing cached data that can easily be loaded again. That way the operating system has control over the memory usage, and it won't have to terminate your app.
I have an app that stacks quite a nice amount of views on top of each other.
At some point I receive a Memory warning level2 (which is kind of expected).
The thing is, when I run Instruments, I don't have any memory leaks and the app takes up something like 9-10MBs... which is not that much, I'd say?
Question is: how much memory can an app consume, a.k.a. how much RAM does the iPhone have?
I know that I can respond the the receivedMemoryWarning and free up some memory - but this would mean that I'd have to get rid of some of the views, which is not the solution I'm looking for...
The app didn't crash so far - but I'm concerned that it might crash on other user's iPhones...
An application can use 30-40 MB of real memory or greater then this and there will not be a problem. When you are getting a memory warning level-1, till then there is not a problem, but if you get memory warning level-2, then the app might or will crash after some time.
solution is, when you get memory warning level-2, inside your delegate method, release some memory which you are not using currently.
You app won't crash anyone's iPhone. The system will just kill your app. Anyway 3GS is rumored to have 256Mb while iPhone 4 has 512Mb. It still won't matter because when you receive a warning you better comply.
Try reducing the amount of views you have or unload the ones which the user can't see.
I am testing a particular use case for leaks. Sometimes, I get the leaks and other times I don't even if I go through the same usecase. Can you suggest whether it is because of the system frameworks or my code?
I have checked in my code and everthing looks perfect without any unreleased objects. Can you suggest a solution?
Thanks
It's extremely unlikely to be the framework. Don't forget that there are hundreds (thousands?) of developers out there using it so the chances of someone not noticing a bug there is rather slimmer than code that's only been reviewed by yourself.
The most likely source for an intermittent memory leak is autorelased objects. Autoreleased objects hang around until the autorelease pool to which they belong is drained. Depending on memory conditions, they may look like they're leaking during one run but then they don't the next run.
See Avoiding, finding and removing memory leaks in Cocoa to learn how to track down memory leaks.
Edit01:
You might get away with it but I wouldn't recommend it. If it leaks while Apple is testing it you stand a good chance of being rejected.
As a quality issue, it depends on how bad the leaks are and how long they can go on during real world use. Every app probably leaks a few bytes here and there. (For example, there are known leaks in some of the frameworks.) If the leaks are very small, they won't cause problems especially on an app that only runs for a short time. However, if the leaks are larger or the app is designed to run for a long time, then the leaks will eventually bring the app down.
For example, suppose you have a program like the weather app. As a quality issue, it really wouldn't matter if it leaked a bit because the weather app is used quickly. People open it, look at the weather and then close it. The leaks don't have time to accumulation. On the other hand, if you had an app like a web browser or a eReader which people leave open for long periods the leaks could accumulate and bring the app down.
In short, like all other programming task, tracking down leaks is a tradeoff between perceived quality versus development. It is very common to spend more resources tracking down a trivial but common bug than to track down a serious but very rare one.
I would reiterate that the memory leak detection methods in the leak above will eventually locate the leak. If you spend the time on it you will eventually find it.
So, I finished writing my first iPhone App, and I have sent it out to a group of beta testers.
Everybody is happy, except for this one guy who noticed that after having run my app, another app is not starting up anymore.
Not knowing too much about memory management, I started looking at the Leaks graphs in Instruments, and noticed, that there are some leaks going on in my app.
Three questions:
Are leaks always bad? The biggest leak is 15k on a total of 5,1 MB allocated memory.
Will Apple refuse my app because of leaks?
Is not all the memory automatically freed up as soon as my app quits? Could it be that my leaking app is harmful to other apps?
Thanks
Sjakelien
Each app is supposed to run in its own "sandbox," and is by design not supposed to affect any other app installed on the phone. If your reviewer found a case where your app really did affect another app, that's definitely not your fault, although I'd love to know how that was accomplished ;).
My guess is, though, that your reviewer's other app broke completely independently of your app, and he/she is spuriously attributing the fault to your app. Ask him to try to reproduce the problem (uninstall both apps, install the other app, install your app).
what the other two answers say i agree with, however nobody has answered the first question ("Are leaks always bad") directly. i would say that yes they are. it's true that your program can possibly run with them for long periods of time without issue. and the OS should clean up the memory after termination (unless there's a bug in the OS, as said before). but eventually the leak will become an issue for someone at some point when they run long enough. also, even if it doesn't become an issue, it's probably a best practice to always fix memory leaks that you know about.
Any leak that persists beyond the exit of your application is an OS bug, and hence Apple's problem.
It would be unfair to reject your app on this basis.
I don't know if that's any comfort to you.
For the record, my app provokes a leak in mediaserverd.
The leak is a tiny bit smaller in the 3.0GM.
Another incorrect usage of an API crashed mediaserverd.
Also 3.0GM. Nasty. I'd have preferred an error code, however
this could theoretically be used to work around the leak.
It depends on what "memory" you are leaking. Are you using device storage space to cache something? In theory then it's possible that you've used up enough space the other app cannot start because it needs a certain amount of free space.
If we're talking physical memory, then no. When your app is dead it is dead. You could ask them to restart the device and see if they have the same issue.
Apple does approve apps that have memory leaks.
That said, we thoroughly check that none of "our code" leaks before submitting to Apple because users don't like having an app suddenly shut down on them. I say "our code" because there are memory leaks in the framework that are not your doing. Thus Apple approves apps with memory leaks.
Also, I am doubtful your app has adversely affected the user's other app. I have not seen that behavior.
I'm afraid I introduced a memory leak or something to version 1.2 of my iPhone app. When I use 1.2 version I notice that my battery drains a lot quicker then with 1.1 version. For comparison, with 1.1 version the battery would last whole day and still have plenty of juice in the evening but with 1.2 I find that I have to plug it in mid afternoon.
Would a memory leak (or a lot of them) cause an increased battery drainage, or do I have something else going on?
The only interesting thing my app uses is AVAudioPlayer class to play some caf audio files. Other than that it's just couple of views with a table view.
I do call AudioSessionSetAcvie(false) in my applicationWillTerminate method, so I don't think it's the audio session that's causing this. I don't have to have my app active for the battery to get drained. It's enough to use it for a while and then exit. So I'm pretty sure I'm leaving something behind, I'm just not sure what.
I tried playing with Instruments tool, but it looks like you can't used with the app running on the device (for some reason my app stopped working in the Simulator)
Any ideas on how to go about finding what's causing the battery to drain?
Memory leaks will not cause increased battery usage. However, if a memory leak persists, eventually you will get a memory warning, and if you can't clean up enough memory, your application will be killed.
Increased battery utilization usually means something is causing your code to continue running. The best way to tackle this problem is to run your application under Instruments (with Sampler probably) and let it sit there in the state that you're confident it usually runs the battery down. Inspect the results of Sampler, and if you have code running, you'll be able to see the stack trace for it.
Hopefully once you've located what code is running, it will become apparent how to stop it.
Memory leaks won't cause increased battery usage, as Nilobject says.
I would try commenting out various areas of functionality, one at a time, to try to narrow down the area that is causing the problem. In your case, the first thing to try is obviously to remove the audio. If, once you've done that, battery usage is back to normal, you know where to look more deeply.
(for some reason my app stopped working in the Simulator)
I would fix that and use instruments to fix the performance bug. It's never a good idea to fix the difficult defect and leave the easy one.