I was curious, when one goes ahead and executes their code for leaks checking with Instruments -- is it prudent to hit all of the parts of the app manually to ensure memory leaks are occurring in that respective area? For instance, I believe I have some memory leaks in my application, deep within a UINavigationController tree. Do I go ahead and run the app checking for leaks, while manually drilling down on the iPhone to get to that part of the app? Is Instruments smart enough to find it on its own? What's the proper way of going about it?
Thanks for any insight!
No, Instruments just monitors the memory allocations of your code, it does not "go" anywhere, unless your app goes there. Actually a leak is nothing more than a piece of memory to that no reference exists anymore; thus it cannot be freed anymore, since how are you going to free it in the future if you cannot even reference to it any longer?
Instruments won't find all memory leaks that way, though. If you keep references to the memory, just never use them to free the memory, Instruments won't see this as a leak, because it cannot foresee if you are going to ever free it up in the future or not. As you still could free it up, it's not considered a leak. So if you have a memory issue, it might be beneficial to not just look for leaks, but also to monitor how much memory your application is "collecting" over the time. If this permanently rises even though it shouldn't, you might still have a leak, just none where you lose the references to the memory.
Typically, I would focus on the module suspected of causing the leaks and then widen the scope afterward. While I have not used Instruments on a Mac, I have used Purify and the native Windows heap tools to do memory leak tracing in Windows programs.
After you have identified the source of your major leak it's never a bad idea to run the program with varying test input and generally check the program for other leaks. Even small leaks with a particular set of data can lead to much larger leaks down the road.
Related
There are some memory leaks found out when i "profile" my app with Instruments.
Some of the leaks are obvious and easy to fix, but some are not. Some of the leak log showed in Instruments are really bothering me. For example:
I even can't tell which line of my code called these "strangers" behind the scene. How can i fix these leaks? Is it a leak from my code? From the framework? Or just a false report?
Then my questions are:
A: Is it possible to fix all memory leak bugs? Some of them are really hard to deal with. And you even can't tell is it a bug from your code or from the frame work.
B: Is it necessary to fix all memory leaks? Couple of bytes leak might affect nothing. And the effort you put on to fix it may cost a lot more than you can get.
A: Is it possible to fix all memory leak bugs? Some of them are really
hard to deal with. And you even can't tell is it a bug from your code
or from the frame work.
Yes it is possible, but please note some times the result you get from profiling dont pont you necessarily to a leak, sometimes they are objects that are not yet been auto released and sometimes they are not yours.
B: Is it necessary to fix all memory leaks? Couple of bytes leak might
affect nothing. And the effort you put on to fix it may cost a lot
more than you can get.
If you mean for your application to not be rejected, then no thats not necessary, dont overwork and stress yourself on some bytes that you cant seem to find, dont go and search for a couple of bytes that has been lost here and there, start looking for leaks only when you notice that your application is really leaking.
Yes it's possible and yes you should.
Leaking ins't good in the long run, especially if you app runs in background.
If the leak is in a third party library, tell the maker to fix it. Or if you have the code fix it your self.
Leaking in you own code can easily be fixed, so do it.
If your application is running for long times(consider as a some server) then it keeps on making that 2 bytes of leak at a frequent of time. At some point of time your heap will be full of infinite leaks. This may leads to malloc failure in your application. So fixing memory leak is more important for application which is running for long time. And also there will be possible to fix all the memory leaks.
If an application is running for short time means, once the application exist all the resources will be freed by the operating system, at that time leaked memory also will be freed.
does an entry in Instruments "leaked block" during application running imply memory leak?
That is, if one is half way through using the iPhone application, where you might have some variables that have been retained but it hasn't got to the part of the application where it gets released, then do these show up as leaked blocks or not?
If the answer is that variables which have not been finished with do show up here as leaked blocks, then this would be quite confusing then if you are stopping/pausing instruments, in which case how would one run instruments in a manner whereby any leaked blocks you see are valid memory leaks? (e.g. need to kill application to end everything first and then look at instruments?)
A leak in Instruments indicates that Instruments cannot find a pointer to the allocated memory starting at any of a group of "root" pointers. Specifically, from the Memory Usage Performance Guidelines:
The Leaks instrument records all allocation events that occur in your application and then periodically searches the application’s writable memory, registers, and stack for references to any active memory blocks. If it does not find a reference to a block in one of these places, it deems the block a “leak” and displays the relevant information in the Detail pane.
So retaining something is not a leak as long as you have a pointer to it in one of your ivars, local variables or static variables. But there are ways that the Leaks instrument can get confused, and sometimes Apple has a leak in their frameworks, and sometimes Instruments has a bug.
The thing you're looking for with Leaks are steady and significant increases in the amount of leaked memory either over time or when doing specific actions. Tiny, one-time leaks are generally not worth chasing.
You should split leak testing into logical units, be it view based or functionalities based. Start from the beginning, test your initial view thoroughly, fix issues, move to next view and so on. I recommend running static analyzer before testing for leaks.
I have been using instruments to check for leaks and other memory issues in my program. Though the leaks found by instruments are extremely small and don't matter, I have found that the physical memory free keeps going down while I use the program.
I use memory monitor to determine how much memory my app is using up and allocations to determine where this is mainly happening. I always make sure to release every time I alloc or retain, and seeing how there are barely any leaks, I'm assuming that my memory management is fine.
Does anyone know what I can do to fix this issue or reccomend a way to get to the bottom of it?
Even tho you release objects you dont need, that doesn't matter. You are probably allocating too much things and keeping them for some reason. You can try to check this out:
http://macdevelopertips.com/objective-c/objective-c-memory-management.html
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
I would advise you to check what you alloc and what you keep for the life of the application and see if you can make the same thing but without using so much memory.
Edit: I have to agree with Mark and Kongress, every leak matters for the sake of your app's life.
I have a navigation based template, when I run my application using Instruments, the very first memory leak comes under:
Leak Object: Malloc 128 bytes
Responsible Library: CoreGraphics
Responsible Frame: open_handle_to_dylib_path
I don't know where this leak is coming from and how remove this.
If it's a default leak, then I think I don't need to worry about it. But if it's not then I have to find a way to remove the leak.
Expanding on deanWombourne perfectly correct answer a bit..
The Leaks Instrument shows you memory that isn't going to be free'd in the normal course of the app (because there aren't any references to it). This in itself is no biggie, it will be free'd when the app exits. A lot of the framework code will allocate and leave these very small chunks of memory allocated. I have no idea if they are mistakes or essential to how the app runs. Whatever, we must accept that they are completely normal.
Leaks will identify these chunks of memory as 'Leaks' and that sounds bad, but this is not really the 'Leaks' that the instrument is there to help you identify.
The 'real' leaks are in the code that can be run many times and which allocate some memory that is never freed, so over time will consume more and more memory until all memory is used and your app will crash.
So if you have an app that no matter how long you use it for or no matter how you use it, it 'leaks' 128 bytes in an apple framework you generally don't have to worry.
However, if you have an app that say, every time you click a button it allocates a new string which is never released - no matter how many bytes the string is - if the user pressed the button enough times this would consume all the memory available to app and eventually crash it. This is the kind of leak you need to watch out for.
The leaks instrument realistically can't tell the difference between the two kinds, but you need to be able to. You might want a kind of singleton object, for example, that there is only ever one instance of, and that needs to exist for the entire lifetime of your app. You create the object on app startup and realistically you never need to free this object, it can be killed when the app exits. Leaks will flag it as a leak, and some other developers that you work with who assume that this means you don't know what you are doing will run to your boss like a little child and say "He's writing really leaky code, and that's reeeeally bad". And your boss, who isn't a programmer will take him seriously because it does sound bad and anyway he scraped a 2.2 in CS from a reputable University so he must know what he's talking about. When really it is completely reasonable and exactly what you meant to do.
So, use the Leaks instrument to find bugs in your code that will ruin your app. Don't worry about every byte found 'Leaking' in an Apple framework.
If it's a one off 128 byte leak then don't worry about it at all, there are better ways to spend your time than thinking about this :)
Another memory question on iPhone - When running the leaks application I see a number of leaks get identified, but are caused by NSFoundation or similar, rather than my application code. Where my application name is mentioned, I have obviously resolved the leak.
I assume I can ignore these and that my app will be approved, or am I reading the data incorrectly?
Also - does the application have to have zero memory leaks before it is approved?
Cheers
Memory leaks will not cause your application to be rejected unless they contribute to general instability - e.g. a leak while moving forwards/backwards between views will eventually cause your app to crash.
Thats said, there are few actual leaks in the SDK libraries so be sure to check the leak are not actually a result of something your code is doing.
Any leaks that apple finds in testing of its own stuff will get fixed (and Apple does definitely test for leaks). The frameworks are not completely leak free, but it's dangerous to assume that a problem is in the frameworks. Here are a couple things to keep in mind:
(1) If you leak an object, the entire tree of objects hanging off it will also be reported as leaks. Suppose an object of class NSPrivateWhosit that you've never heard is leaked. Does that necessarily make it Apple's problem? No, it might be something used by an instance of NSPublicClass that you leaked.
(2) If an object is allocated in Foundation and passed to you, and you retain it, then you can leak it. The backtrace of the allocation doesn't matter. What matters is the backtrace of the unbalanced retain.
Your application will get approved even with memory leaks (at least my buggy application did get approved).