i am working on project in which application memory usage increase continuously even i am on same view and app in idle
i am using ARC, dealloc also not called.
most on my properties are nonatomic and retain.
XCode has a built-in memory profiler that can help you with this issue - for a tutorial on how to use it, this might be helpful http://www.raywenderlich.com/23037/how-to-use-instruments-in-xcode
Otherwise, if dealloc isn't being called it could be a symptom of a retain cycle (two objects maintain strong references to each other, so they are never deallocated).
You can find fix the Memory Leaks using Analyze option of XCode
Open XCode --- Product --- Analyze
Then you can find the memory allocation issues locaton with blue identification.
You can fix them where you not using any object which are allocated and so on....
Hope it helps you..
Related
As I start working in swift, I am curious in memory mgmt. As we all know that during any object creation or assignment of data into that object it takes memory. How can we check that a particular object has released the memory. I used xcode memory report to see memory status and fluctuations.
Here is a sample of images:
How can release memory if I already set nil into the objects.
Use instruments to track the lifecycle of an object than just Xcode because it gives you the allocation details at much higher level.
Check out the answer at https://stackoverflow.com/a/14891837/5133769. Though it was explained with old instruments it still works.
Some objects are very small and it could be difficult to see in Memory profiling which one is released. This tool is helpful for finding memory leaks in an app. To check was some object released from memory or wasn't you can setup breakpoints or logs in dealloc() method for objective c and in deinit() method for swift.
Using instruments checking for leaks or allocations is the recommended way.
You can also set breakpoints or add logs to the dealloc method.
As I learnt from the apple documentation that ,In iOS ARC will automatically take care of the memory leaks and memory management.
But my doubt was, do we still need the role of Xcode instruments (Allocations and Leak) to ensure whether memory leak has happened in our application??
Please do share if you know the solution.
Yes, of course you need to use Intruments.
Swift uses Automatic Reference Counting (ARC) to track and manage your app’s memory usage. In most cases, this means that memory management “just works” in Swift, and you do not need to think about memory management yourself. ARC automatically frees up the memory used by class instances when those instances are no longer needed.
However, in a few cases ARC requires more information about the relationships between parts of your code in order to manage memory for you. This chapter describes those situations and shows how you enable ARC to manage all of your app’s memory.
You should take a look over Automated Reference Counting.
One of the most common situation is when you have strong reference cycles between class instances, because the compiler doesn't know when to release that part of memory. Also take a look over the differences of strong and weak references.
But as even Apple saids, "In most cases", you should be ok without, but if your application crashes, it could be that you have memory issues.
Automated reference counting provides a new, simpler, way of managing reference counted objects. By automating the tasks of calling retain and release it eliminates a large class of memory leaks and invalid references caused by programmers forgetting to call memory management functions.
However, ARC does not eliminate a different class of leaks caused by logical errors in the design of your code, when your object graph has cycles. ARC provides tools for you to address this issue by adding weak references, but if you don't do it right, there is nothing ARC can do to help you.
In addition, you may have "lingering references", when an object remains in memory even though your program no longer needs it. Memory leaks of this kind can happen even in garbage-collected environments, such as Java and C#. They represent a logical error in design, and cannot be eliminated by clever compiler tricks in the current state of compiler technology.
This is when Xcode memory tools come in handy. You run them to check for memory leaks, ensuring that your code does not have cycles and "lingering references".
I am developing iPhone App. i am using NSThread for continuous calling of function which contains C++ code.
when i use NSThread or dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),^{
Function calling
}
then it gives me "Received memory warning" warning after 5min and crash the application.
but when i run this function on main thread/Queue then it works perfactly.
also i have tried Xcode profiler for check memory leaks but no memory leaks found.
how can i resolve this issue?
thanks in advance.
Instruments may not see all memory leaks especially if you are calling some C code as you are by passing the retaining functions.
It's hard to give you an answer without knowing what your thread contains but you may want to check your code for unreleased object / mis-deallocated / destroyed objects.
You should also check that you are not creating a whole bunch of threads (NSThread) and that they are correctly releasing their contents after termination.
By the way, your app shouldn't terminate when receiving a memory warning, it's a normal message coming from the OS. Check your deallocation when viewWillUnload / didReceivedMemoryWarning functions are called.
You should also try to create memory warning manually using the simulator
I had a somewhat similar problem using a NSOperationQueue on a background thread.
Assuming you have already declared you mandatory NSAutoreleasePool in the function, you could try to allocate/release the objects yourself and don't use autorelease unless necessary, to make sure the memory is freed right on time.
A second advice would be to use Instruments and Allocations, to see what exactly takes up your memory. Probably you have some object being retained and not released when it should be. This post is AMAZING when it comes to this http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ and you might also find some useful info here http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/
Otherwise... you need to post more details.
Good luck!
I've kind of a weird issue with my iOS app.
after a while my app goes low in memory so memory warning, everything seems to be fine, but when I check the memory usage I noticed that all the calls to viewDidUnload didn't free up lot of memory, so after a few click in my app, it goes again in memory warning, everything seems to be fine again, but not a lot a memory have been released, so it goes again in memory warning faster, and then it crash (after the third memory warning most of the time). this crash is random : app freeze, app leaves, my debugger says app paused, but no bad access or sigbort, no zombies.
my guess is that memory warning can't free up enough memory has it should.
(I checked all my viewDidUnload and make nil every objects that are allocated in viewDidLoad)
Any help will be usefull !
thanks a lot.
So I managed to work with my issue.
I wrote "-(void) dealloc" methode in all my controllers and check if I enter in it as I should. (on pop controller, dissmiss etc..)
Every time it didn't, I do step by step in the controller to see what was retaining my controller from beeing dealloc.
most of the time it was some property that was not in "unsafe_unretained"
delegate that was in "ASSIGN" (and should not be in assign but in unsafe_unretained)
(heritage from non-ARC project...)
I also had some strange controller with XIB that was not deallocated even if empty.
I rebuild new one step by step with copy/paste and finaly with exactly the same code, the new controller was released, with no visible difference between then !!! gnneee
at least I know how to debug that kind issues now...
I don't think there's any way to give a specific answer without more data so the best I can do is suggest that you stop guessing what might be happening with your app and learn how to measure what is actually going on. Run your app under Instruments and you'll be able to check for leaks and also actually see what classes are responsible for the most of your application's memory footprint.
You should make sure you know how to use both the Leaks instrument to identify leaked object but also the Allocations instrument to identify orphaned (but not leaked) sets of objects which should have been released or just cases where your app is not responding to memory warnings as you expected.
https://developer.apple.com/library/ios/#documentation/developertools/conceptual/InstrumentsUserGuide/AboutTracing/AboutTracing.html might be a good place to start and there are a number of tutorials available as well; http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial and http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ are among the first results I saw.
Vassily,
First, if you aren't yourself releasing extra memory, the the -didReceiveMemory warning does you no good and the OS will keep asking for memory until you are killed. This sounds like it is your problem.
Second, if that isn't the problem then you are probably getting terminated due to the size of your resident memory partitions. Make sure you look at your VM allocation in Instruments. I expect the MALLOC_TINY or MALLOC_SMALL both have greater than 5 MB resident and dirty footprints. Due to the nature of small allocations these VM regions will never shrink. The only option you really have is to not create a lot of small items in the first place. This is really only something you can address by changing you code's algorithms to use less memory.
Andrew
Instruments can visualize retain cycles under ARC in a graphically interesting way. I also remember that a few days ago I spotted the "Cycles" view in Instruments by accident.
Now where I started using ARC, suddenly I'm not able to find that anymore. The Allocations and VM Tracker instruments don't offer it, and the Leaks instrument either.
What must I do in order to see retain cycles?
Found a screenshot as evidence:
Using Xcode 4.2.1, I found the it in "Leaks", under "Cycles & Roots". However, I've found it less than useful when using ARC. It does detect CF leaks and apparently I'm leaking a recursive block, which I can't do anything about, but I've had to root out several retain cycles that Leaks never found. For finding retain cycles, I recommend using "Allocations" and running several heap shots between performing the action you suspect of 'leaking'. You then then look through the interim heap shots to find the culprit.