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
Related
My app starts with about 3 MB Live Bytes, and after 10 minutes of use it reaches 6 MB and also gets some Low Memory Warnings. But there are no Memory Leaks discovered by the Leaks instrument.
What can be the cause for this?
As #viggio24 says, there may well be an "abandoned memory" problem such as cashes that are not released retain cycles, etc.
Try Heapshot Analysis, bbum has a great tutorial here.
Basically you take a Heapshot, run some procedure, take another Heapshot for several iterations. This will help find memory that lost but not a leak. I use this method often,
I have used Heapshot many times to great advantage, many thanks to bum.
You are just using a lot of memory. A leak occurs when you load something into memory and then stop referencing it before you have released it. In your case it sounds like you are loading items into memory that you still have active references to so they don't show up as leaks.
This is a typical case of "abandoned memory". Not a leak in the strict sense of the definition, but almost. This means that you have retained some objects, you have not lost the references to them (so they are not leaked and analyzer and instruments don't trigger them) but you simply forgot to release them.
This is typical when you do some sort of internal caching (e.g.: images) and then you don't clean this cache of data which is no more needed.
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.
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.
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.