I'm having a difficult time understanding where actual Leaks are happening and where they are not in my application using Instruments. I have objects which are autoreleased and not being retained afterwards.. that are showing up as leaks via Instruments. There's also a bunch of objects which are listed as leaking that don't point back to any code that I've written myself. Perhaps it's a domino effect where one of my real leaks is causing stuff within the Apple libraries to leak, but I'm reluctant to believe that is the case. What's the best way of differentiating where the real leaks are happening?
In my experience Instruments does not give false-positives for auto-released items. (these are still referenced by an auto-release pool so there's no magic difference).
With memory leaks there can indeed by a domino effect in that one culprit results in many cascading leaks. Within instruments each leak will have a time based identity so I suggest you start with the first leaks.
Related
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 don't have any problems with my iphone app. Theres no exc_bad_access or memory issues. However I know that I haven't properly allocated and released memory. I don't know why this isn't throwing any exceptions, but it isn't. Everything works.
I don't want to overload the iphone memory though, and am aware that just because I don't release an object doesn't mean its not still using memory, but now I am quite far through my app I can't be dealing with going back through and analyzing the whole program.
Is there any way of finding pointers and their retain count or find memory being used or anything?
Thank you.
You can use the tools that come with Xcode to detect both leaks and allocated objected. From Xcode, select Run > Start with Performance Tool > Leaks. Then choose the ObjectAlloc instrument. This will display all of the objects in memory.
This will only discover used memory for active objects, but not the retain count for individually allocated objects AFAIK.
If it's not throwing any exception it's because or you are keeping the retain count >= 0.
If you are not sure if the retain counts are equals 0, and you are concerned of leaking memory, you should run the Leaks instrument (Xcode->Run->Run with performance tool->Leaks).
You can also run the static analyzer to check possible leaks or other issues on your code (Xcode->Build->Build and Analyze).
Cheers,
vfn
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).
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.