Our app is experiencing occasional crashes in the field (discovered via BugSense) due to what looks like out of memory or memory corruption conditions, so to help me track them down I enabled the following:
Malloc Scribble
Malloc Guard Edges
Guard Malloc
Objective-C Zombie Objects
Malloc Stack Logging
Log Exceptions.
After interacting with the app for a bit in the Simulator (less than 30 seconds), the following message is displayed:
GuardMalloc[TrafficDemoEmp-2430]: allocate_pages(): virtual memory exhaused!
GuardMalloc[TrafficDemoEmp-2430]: expandUniquingTable(): VMCopyFailed
GuardMalloc[TrafficDemoEmp-2430]: allocate_pages(): virtual memory exhaused!
GuardMalloc[TrafficDemoEmp-2430]: expandUniquingTable(): VMCopyFailed
With Guard Malloc disabled the app works fine but with it enabled the app crashes with these messages. When I profile with the Leaks and Allocations instruments no leaks are found and the Live Bytes value for all memory ranges between 30 MB and 80 MB (depending on what it's doing at the time). Surely that's not too much memory for an app.
However, the messages point to my app using too much memory but I'm not sure what is leading to the virtual memory exhaustion. Are there other tools or debugger settings that are available in Xcode to help?
Thanks,
David
User1118321 was right. NSZombies was the cause of this problem.
Filing this answer so an answer can be accepted.
Related
When I run my app using Instruments, I face the following issues before the app eventually crashes:
Allocations: There is a constant increase in total bytes up to 1-2GB. This increase is seen even before any leak is detected.
Leaks: There are multiple leaks. On looking at the Call tree, I find they are in the system libraries:
with symbol names, malloc_zone_malloc and malloc in libsystem_malloc.dylib
the bytes used column shows 192 Bytes, 100%
When I run it in xcode, I get a 'terminated due to memory pressure' error.
My questions are-
Is filing a bug report with apple the only solution since the leaks are in system libraries?
Are the leaks, the only reason behind the crash; given that only 192 Bytes are leaked and memory usage increases even before leaks?
When troubleshooting memory allocation and leaks it's almost always a good idea to exclude system libraries and look for your code only. It's very unlikely that you have discovered such basic and easy to find bug in core libraries and nobody took care of this before.
The facts that leaks are indicated in malloc doesn't mean anything. All memory allocations will go through mallocs at the end. You need to look for bugs in your code first.
I am stuck with an issue in my app. I have been testing up until now mostly on my iPad 3 with occasional checks on my iPad 1 to make sure all is well.
I am playing a UIImageView animation in my app and it keeps quitting with only a "Received memory warning" message before it quits.
I have been using the Object Allocations tool in instruments but according to that, my memory usage is way low. So after researching for a bit I came across this post by Mr. Larson: https://stackoverflow.com/a/5627221/329900
Now I am using the Memory Monitor tool instead. However, I don't understand why I am quitting. The 1st gen. iPad has 256MB of ram. Now I know I can't use all of that...some say you shouldn't use more than 100MB.
Is that real memory though, or virtual memory...or maybe some combination? My real memory is consistently between 20 - 25MB but the virtual is around 190 - 205MB when it crashes.
Here's a screenshot:
Anyone able to shed some light on this?
The WWDC (Session 242) video found by searching for iOS App Performance: Memory in the WWDC 2012 Session Videos page will give you a better understanding of the difference between VM and real memory.
But here is a quick overview:
A pointer Range = 2^32 = 4GB This is larger then the physical memory on any device(apple has shipped). This is done by taking all available space and dividing it up into 4kb chunks. Not all the memory your application can access is in physical memory at the same time. These 4kb chunks are call pages. Your allocations get split out of larger chunks of virtual memory. Then these virtual memory objects get mapped to physical memory.
Is there a way to retrieve information about the memory of the ipad during running?
For example, i would like to print in the console the use of memory at t instant.
Thanks
You should instrument this instead of trying to print a number. That number is not really useful. What you care about is your application's dirty memory footprint for memory pressure on the device and how much code/mapped ro mem you're evicting to see if you're essentially thrashing and causing performance problems due to memory pressure.
The other info you can get, like device inboard memory and how many pages your app has allocated are not useful because you don't know how much of that memory is wired to other devices or the kernel and you don't know how many of your allocated pages are faults at that point.
I'm in the process of understanding how to put instruments to better use. I just finished a leak management exercise, and instruments is reporting very few leaks. I'll figure those out later. In the mean time, my app is crashing, and it appears that its related to memory pressure.
So I looked at this in Instruments. I have Allocations and Memory Monitor in use. Allocations shows a pretty steady 3 to 4 MB Live bytes while I just let my app initialize and come to equilibrium. Overall bytes, however, jumps to over 50 MB. I didn't think much of this until I looked at the Memory Monitor and I see that memory usage goes up and down, causing memory warnings. (It seems strange to me that this doesn't show up on the allocations graph at the same time.)
The app should be at an equilibrium point, but apparently it's not. My question is how can I use instruments to help me understand why memory usages is rising and falling?
Instruments as a tool for debugging is simply excellent. From what I can understand, you have been trying to use the allocations tool, so I'll go over that. Allocations details the number of objects your application allocates during it's execution, along with their in-memory references, locations, even the calling code that allocates said objects. When instruments starts running the allocations tool, your application begins reporting all allocations as blue dots, which pile up higher and higher as your application executes (naturally, as you should be allocating more and more objects). Overall Bytes displays the amount of memory EVERY allocation your app has made added together. I want to stress this for your case: it does not mean your app is currently using 50 mb of memory!, it just means that your app has used 50 mb total. Your app is obviously limited to the amount of memory the device has, and 3-4 mb is not a lot when you consider that the first gen. iPhone had about 128mb, but for more complicated applications, the OS will usually kill off other applications before it kills yours.
As for the other allocation graph with spikes, rather than a continuous line graph, that is to detail the number of allocations going on at that point in time. Usually, the spikes can be ignored, unless there are a lot of large spikes in one small amount of time.
Anyways, to address your specific memory warning problem, it honestly depends how many memory warnings you are receiving, and at what level the warning are at. And as for your leaks, my only word of advice is: Squash them as soon as possible! When you see a leak (a red bar in the leaks tool), click on the bar and find the objects that are being leaked. When you select a leaked object, then select the right sidebar, it will show you the code that is leaking. When you double click on any part of the right sidebar, it'll even open up the specific line and class the leak originated from!
I want to make sure I'm reading the allocations plug in correctly. I'm testing an iPad app thats receiving memory warnings 1,2 & 3.
I want to know the current used up memory from my app, which I think it has to be the "Live Bytes" column? which marks All Allocations to 2.42 MB which I think its low.
What do the other columns report? #Transitory, Overall Bytes ?
Also if my app uses only 3 MB of memory can it be killed if I get a memory level 3 warning without releasing?
Thank you.
Don't use the Object Allocations instrument for looking at your total memory usage. It does not display the true total memory size of your application, for reasons that I speculate about in my answer here.
Instead, pair Object Allocations with the Memory Monitor instrument, the latter of which will show the true total size of your application. I'm willing to bet that it's way larger than the 2.42 MB you're seeing in Object Allocations (for example, I had an application with 700k of memory usage according to ObjectAlloc, but its actual size was ~25 MB in memory). If you are receiving memory warnings on an iPad, your application is probably chewing up quite a bit of memory.
Object Allocations is handy for telling you what you have resident in memory, but it's not an accurate indicator of the size of those items. It's also a great tool for showing you steady increases in allocated objects by using the heap shot functionality (the "Mark Heap" button on the left-hand side of the instrument).
Your memory usage looks fine. Check to see which app is being sent the memory warnings, it is probably not your app assuming your app is not in the background. The only way you should be getting memory warnings is if the app is in the background and another app needs more memory.
When I was looking at logs I noticed other apps were getting them while my app was running, other apps such as Mail or navigation apps (Navigon) do run in the background and will cause memory pressure. You might get a memory warning but should not be terminated.
For a description of the memory columns see Explanation of Live Bytes & Overall Bytes.
As #Brad points out use the memory monitor tool as well.