I'm working on a Mac app. Initially monitoring Xcode's memory report while I ran my app showed showed the memory was just ramping up crazy. I used Instruments and profiled my app for allocations and leaks. Turned out there wasn't much leaked memory as you would expect due to strong reference cycles etc. However there was a lot of abandoned memory. By following the stack trace that lead to my code I have fixed by 70% using autorelease pools etc. Still the remaining 30% of abandoned memory seems to point system calls.
Now I have two questions based on that I have two questions
1) I want to fix the remaining 30%. How can I get rid of abandoned memory? I have already used Instruments and know exactly where those system calls are spawned but still dont know what to do to have that memory be cleaned up. (using ARC no manual retain/ release and autorelease doesn't seem to make a diff.)
2) After I know whatever my application was doing has completed and there is no need for any memory to be there (just like the application first started) I want to get rid of all memory that my app has used up. This I plan to use as a brute force approach to clean up all memory just like the system would if the user closes the app or turns off the system.
Basically if I know where my apps memory is in the file system I'll just programmatically call purge command on that or something similar. Because at this point I'm 100% sure nothing needs to be in memory for the app except for the first screen that you would expect the first time you launch the app.
I read this, this, this and this but they weren't helpful.
I followed this video tutorial for detecting memory leaks using Instruments with Xcode 4.3.2.
As you can see from the video, the creator gets a lot of useful feedback on the type of object that was leaked etc.
When I run instruments, I detect a few memory leaks but don't get much useful feedback on them:
What does it mean "Root Leaks"? Why is there no more useful information like in the screen above?
Is this something I can fix?
I'm using ARC within my app - does that effect Instruments finding memory leaks in any way?
A root leak can be one of two things. It can be a single memory leak, or it can be the start of a leak cycle. A leak cycle occurs when you lose a reference to a group of objects. A memory leak leaks one object while a leak cycle leaks a group of objects.
Your code may not have any leak cycles, which would explain why your Cycles and Roots section shows less information than the tutorial. Choosing Call Tree instead of Cycles and Roots from the jump bar can help you find the areas of your code that are leaking memory.
I'm trying to debug a mysterious app crash that happens after running the app for a few hours.
My hunch is that this may be memory related, as I've not done any memory optimization since starting to build my app.
I'm looking at my application with the "allocations" instrument and I see these numbers:
All allocations 4.70mb
Living 51072
Transitory 357280
Overall Bytes 100.23mb
Overall 408000
Which is the important number here? Does my app take 4.7 Mb of memory or 100 Mb? At which point should I be concerned about my app being killed for memory reasons? I want to avoid premature optimization :)
Since I'm using ARC and TabBarController, most of the controller related memory seems to be out of my hands, unless I find out how to create a tab and lazily init a controller when that tab is first touched.
Thank you!
I am working on an app with xml parser, uiwebview, navigationcontroller, displaying a lot of images on the main controller, that remains in the memory throughout the whole life of the app. I store my data using core data.
I tried to figure out the memory footprint of the application since I am getting the following warnings:
Received memory warning. Level=1 app delegate received memory
warning main controller received memory warning main controller
received memory warning RSSItem received memory warning
Received memory warning. Level=2 app delegate received memory
warning main controller received memory warning main controller
received memory warning RSSItem received memory warning
The footprint is around 4MB, and jumps up to around to maybe 10 when I drill down and display UIWebViews with a significant number of images.
Is that footprint too large? I assume that there are apps out that are considerably more complicated. From what I understand the apps have 40-70MB available, give or take, but definitely not 10MB limit. Anyone has any insight what can I do to fix it or work around the problem. I do not have leaks.
I am afraid that the real problem is not the footprint but something else I am not aware of.
Thanks for any help.
you have memory analysis tools in Instruments.app - this will show you much data related to allocations in your app.
if i had to guess: destroy images which are not visible.
i've been playing some time with different builds of my application and there seem strange things to happen:
my app has a 5mb idle footprint. when uploading a file memory in size of the file is reserved. after the upload the reserved memory should be freed. now there are differences in the builds (gc = garbage collector):
32bit i386 no-GC: all memory is freed instantly.
32bit i386 GC: almost all memory is freed instantly. the rest some time later.
64bit x86_64 no-GC: minimal memory is freed. like 10%
64bit x86_64 GC: no memory at all is freed. the memory stays reserved for hours. (activity mon)
i'm using LLVM with CLANG. i have been running today instruments all the time and was checking for leaks/zombies/etc. and everything seems to be clean. (the app is rather simple.)
is there an explanation for this behavior?
Update:
That's some weird stuff. I've boiled the problem to this:
I load a 20mb file into a NSData and release it. I'm doing this without any garbage collection enabled. The code is:
NSData *bla = [[NSData alloc] initWithContentsOfFile:#"/bigshit"];
[bla release];
When I build for i386 32bit the 20mb are allocated and released. When I switch the build to 64bit x86_64 the release does nothing. The 20mb stay allocated.
upper pic 32bit lower 64 http://kttns.org/zguxn
There is no difference between the two apps except that the upper one is built for 32bit and the lower one 64bit. There is no GC running. (With GC enabled the same problem appears.)
Update 2:
The Same behavior can be observed when I create a new cocoa app from scratch with only the upper code in applicationDidFinishLaunching:. In 64bit mode the memory is not released. i386 works as expected.
The same problem appears with NSString instead of NSData. It also appears when I boot the 64bit kernel. (Holding 64 at startup.)
OS is 10.6.0
First, use Instrument's Object Graph instrument to verify that the memory is no longer considered to be in use; does not have a retain count or a strong reference somewhere.
If it is no longer in use, then the memory is sticking around simply because you haven't hit the threshold at which the collector cares.
However, this statement:
64bit x86_64 no-GC: minimal memory is
freed. like 10%
Makes me wary. Specifically, if your code is designed to work in non-GC -- with retain/release -- then either (a) you have a memory leak and, if using CFRetain or some kind of global cache, that might impact GC or (b) you aren't using the right tools to figure out whether or not you have a memory leak.
So, how are you determining that you are leaking memory?
Update; you are using Activity Monitor to monitor the RSIZE/VSIZE of the process. This won't actually tell you anything useful beyond "is my process growing over time".
More likely than not (I haven't looked at the source), this code:
NSData *bla = [[NSData alloc] initWithContentsOfFile:#"/bigpoop"];
Will cause the 20MB file to be mmap()'d in to the process. There isn't a malloc() style allocation involved at all. Instead, the OS hands 20MB of contiguous address space to your process and maps the file's contents into it. As you read the contents of the NSData, it'll page fault in the file as you go.
When you release bla, the mapping is destroyed. But that doesn't mean that the VM subsystem is going to reduce your application's address space by 20MB.
So, you are burning up a bunch of address space, but not actual memory. Since your process is 64 bits, address space is pretty much an infinite resource and there is very little cost to using addresses, thus the reason why the OS is implemented this way.
I.e. there is no leak and your app is behaving correctly, GC or no.
This is a common misconception and, thus, star'd the question.
A garbage collector doesn't necessarily release memory immediately.
In the case of the Objective-C garbage collector, you can send Cocoa's garbage collector object a collectIfNeeded message to suggest that now may be a good time to do some collection, or collectExhaustively to order it to immediately start collecting any and all garbage (but even this is interruptible). See the docs.
I have a very similar problem in iPhoneOS 3.2 and I really don't think that the memory is being reclaimed -- I eventually trigger memory warnings. There is a small chance that I have overlooked a mistake of my own but I have been very thorough.
I use NSKeyedUnarchiver's unarchiveObjectWithFile: to load a custom object that contains a single large NSData and another much smaller object. The dealloc method in my custom object gets called, the NSData object is released, its retainCount == 1 just before. Physical memory does not decrement by any amount, let alone a fraction of the NSData size, and with repetition memory warnings are reliably generated: I have test until I actually received level 2 warnings. =(
Before release:
(gdb) p (int) [(NSData *) pastItsWelcomeData retainCount]
$1 = 1
After release:
(gdb) p (int) [(NSData *) pastItsWelcomeData retainCount]
Target does not respond to this message selector.