I am making an iPhone app which lets the user create and store up to 4 images.
However the app sometimes crashes anywhere between taking 2-20 pictures (as in taking some pictures, deleting them, taking them again etc).
The problem is my app will crash at some point without a memory warning, stack trace, or anything.
When I run my instruments tool, I see that my allocations don't seem to get even half way to the allowed memory usage. But I KNOW the only reason you get crashes without messages means a very fast over-use of total app memory.
So my question is:
Is there something else to the Allocations instrument I can dig into to get my 'true' app allocation amount?
Clearly something is hogging my memory and the default allocations instrument I am using is not showing me what I need.
Related
I'm new to Xcode and iOS and have been experimenting today with the Instruments tool. There are some things I'm struggling to get my head around:
Scenario:
I have created a simple app that filters a UITableView with a UISearchBar (target iOS5 with ARC). Simple code, nothing too fancy.
For my own learning, I was watching the allocations as I perform various actions - in this particular instance when I'm typing in the search bar.
Using the 'Allocations' instrument tool, I get the following:
As expected, I see a sudden spike in memory allocated when I first start typing in the search bar. After that, any further searching makes no significant difference to the allocation graph.
However, when I look at the memory allocations using the 'Zombie' instrument tool, the allocation graph continues to rise whenever I type in the search bar.
At first, I thought this may have been to what I was tracking - and I tried to ensure all the settings were matched. However, it still shows a rising graph when searching.
Does anyone have an explanation of this? No doubt I have some conceptual misunderstanding about what the allocation tool is tracking in each of these instrument modes.
The Zombies instrument works by telling your app not to free objects. Instead, when the object would be deallocated, the app instead leaves the object allocated but changes the object's class to a special zombie class that handles any message by raising a zombie error.
Thus, allocations keep rising under the Zombie instrument because nothing is really deallocated.
Incidentally, since using Zombies prevents the app from deallocating objects, the app usually requires much more memory to run under the Zombies instrument. This is ok on a Mac (and in the iOS Simulator running on a Mac), since the Mac probably has several gigabytes of RAM and also supports paging to disk. But iOS devices only have between 256 MB and 1 GB of RAM, and don't support paging. This is probably why Instruments won't let you use Zombies on an iOS device.
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!
So I'm trying to get my first app ready to submit to the app store, and I'm at the profiling/analysis stage of it. My app is crashing, and I have some questions I can't seem to dig up answers to.
I've been running my app through Instruments checking allocations and leaks, and it's been crashing fairly regularly. The weird part is that allocations says my total is only 2-3MB, and while I do have a leak, Instruments shows only an occasional ~300 bytes (about once every 2-3 minutes with heavy use), but I'm still getting low memory errors and signal:9 killed:9 when it crashes.
Are there things that Allocations isn't showing me? (i.e. storyboard initialized views, or memory allocated on background threads)
How significant a problem is my small leak? I'm obviously working to stamp it out, but is it likely that this is just a red herring? Or could it be the cause of my crashes?
I did some HeapShot analysis (credit goes to bbum for the awesome walkthrough) and found two instances where I WAS in fact leaking memory, just in a way that wasn't being captured by the Leaks instrument.
App's been running steadily through a few more days of testing, so it seems alright now.
I have a strange memory issue I'm having problems resolving and would appreciate some advice as to where else to look.
The program I have (iPhone App) has a function whereby it basically downloads loads of files, processes those that are JSON, and stores the rest to disk. The JSON processing is CPU intensive and can take several seconds per file, so I have a NSOperationQueue with maxConcurrency limited to 1 that handles all the heavy lifting, and a queue that manages the multiple files to download.
Ever since iOS5 came out, the App has had problems completing the download sequence without crashing and so far what I have tried is;
1) Changed the performSelectorOnBackgroundThread JSON processing to use a single NSOperationQueue so as to limit the number of background threads working with large objects.
2) Added NSAutoReleasePools inside loops that create multiple, large, transient objects.
3) Flushed the sharedURLCache to ensure the files aren't hanging around in the system cache.
4) Stored the JSON objects to disk using NSKeyedArchiver and passed the filenames between threads rather than the actual objects, to again try to mitigate the number and size of retained objects currently in use.
All of these at first seemed to make a difference, and when I look at the memory allocations, I've now got the peak usage down from just over 20MB (hence no wonder it was crashing) to under 10MB, and yet the app is still crashing with low memory as before.
I'm trying to trace what is eating the memory causing the app to crash and on this occasion I'm having real problems persuading Instruments to tell me anything useful.
Here's a typical trace (on an iPhone 3GS running iOS 4.3.5)
You can see that the PEAK usage was a tad over 7MB and yet shortly after, you can see the 2 flags pertaining to low memory, and then low memory urgent, followed by the app terminating shortly thereafter.
If I use the memory monitor, the cause of the crash seems clear enough - physical memory is being exhausted - look at the light green trace below. The low memory warnings co-incide (not surprisingly) with the physical memory running out.
There are no leaks showing FWIW either (I've done that in other runs).
It's not image caches or NSURLConnection caches and the only thing I can think of is that perhaps there are some bad leaks that aren't being detected ... but I'm having issues identifying them because if I click into all allocations to see the objects that are live, and then do a command-A to select them all (in order to paste them into a spreadsheet to see where the memory seems to be), at the point I hit command-C to copy them, Instruments beachballs and never recovers.
I really cant figure out what's going on. Does anyone have some advice on how to persuade instruments to show me some more useful information about what is using this memory?
Sorry I can't post any meaningful code fragments ... hopefully the instruments screenshots at least give you an idea about where I'm coming from.
The Leaks instrument isn't terribly useful for figuring out anything but the obvious leaks in your app.
What you are describing is an ideal candidate for heapshot analysis.
tl;dr Heapshot analysis allows you to see exactly how the heap of your application grows between any two points of time (where you determine the points).
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.