iOS : ARC, not freeing memory

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)

  • What are the new type qualifiers introduced with ARC?
  • ARC delegate memory management
  • Who is responsible for releasing objects in an array when copying?
  • Why does this create a memory leak (iPhone)?
  • Release in viewDidUnload and dealloc both?
  • Manual retain with ARC
  • Any help will be usefull !

    thanks a lot.

    3 Solutions Collect From Internet About “iOS : ARC, not freeing memory”

    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