I have an iOS 3.2 program running on the iPad that is document-centric. Sometimes, when closing a document, there is a memory spike in Instruments. I'm pretty sure I'm not leaking memory, since the allocations graph stays pretty steady between 5mb and 10mb, except when closing, where it spikes up by about 5mb or so (and the leaks tool is showing very small leaks, a few k total, nothing that I'd expect to cause crashing).
This seems to be leading to iOS getting fed up and jettisoning my app. The memory use never goes about about 12mb, but the error log report displays that it's using 19988 "Count resident pages", which is way, way higher than anything else.
My problem is that I have no idea where the spikes are happening or why. It's the same code, over and over, and sometimes a document will spike, other times it won't. There doesn't seem to be a way to use both the debugger to step through the code and Instruments to see what's going on at the same time, so I'm not sure how to track down this problem.
Is there a way to see the memory use in the debugger?
IIRC, Instruments should have an Allocations tool which would show you what is demanding all that memory. If you open up the right side bar, there'll be extra information which shows the code path it used for that allocation.
Related
From using the Allocations instrument to track my app's memory usage I've noticed that throughout the runtime of the app the memory usage keeps going up. Looking through the heapshots I can see that the largest chunks of memory are being allocated by a method called CJPEGCreateImageDataWithData in the library GMM. I can't find anything online about this happening, but it certainly looks like this is responsible for my app's memory-hogging. Here's a screenshot of the pertinent part of the Allocations output:
What might be the reason for this, and how would I avoid it?
The simulator and the device use a different amount of memory due to several factors.
MKMapView should behave well enough on iOS 4.2 or higher. Even when you see a steep memory increase, note that it is cache memory, and all that is not required by MKMapView to work. The only problem is that it may bring your application closer to a low memory warning. You can emulate this warning and see if your app survives. Other than that, you can't control the map cache directly. If you don't have enough memory for your app to work, try using the normal map instead the satellite one.
This question is NOT about retain/release things in iphone memory management. I understand the routine quite well and there is no memory leak things in my app.
I pop up the question shown in the title, when I use Activity Instruments to monitor the overall memory activity of my app.
The instrument always shows that the amount of "real memory", which my app is using, keeps being between 21 MB and 30MB, never higher. I think this amount is relatively not big. However, sometimes, my app will give level 1 or 2 memory warning (never crash and I don't do anything for this warning in my code).
so I am wondering what's really behind iphone memory thing. I mean, does real memory the only things that triggers warnings? or there is anything else (such as virtual memory, as shown in the Instruments) inside the whole memory I should take care of?
Although my app never crash due to memory issues, this warning thing (especially level 2 warning) really annoys me and makes me fear of crashing once I release it to public in the future.
Any help?
Thanks
Memory warnings exist to tell your app you're nearing your limit. They are not necessarily a 'bad' thing - plenty of applications simply ignore them.
The actual implementation details about when a memory warning is triggered are not important, and in fact will vary considerably from device to device. An iPhone 4 might have 512MB of RAM to play with, but a 3GS will have half that.
That said, there are some things worth knowing about memory warnings:
A memory warning is triggered when the overall amount of available free memory reaches a certain level
These levels are undocumented. So you don't know what the difference is between a level 1 warning and a level 2 warning, other than the fact 2 is worse (more urgent) than 1
Memory warnings are not application specific. A memory warning is delivered to all applications currently running and not suspended. So you may not be directly responsible for triggering one.
When memory warnings are received the system will try and free up memory on your behalf
Again, the exact implementation details are undocumented, and you shouldn't need to care about them. A memory warning is an opportunity for you to help the system by freeing up any objects you don't need.
I have a quite a big iPad app and when I run the app in xcode debug mode, it shows about 50 MB in the Activity Monitor and memory grows slowly. (About 0.1 MB per 30 seconds approximately.) But when I run the app directly from the simulator(which is already installed in the simulator) , it shows about 10 MB in the activity monitor and memory is not growing.(its constant). I have checked the performance though the instruments and no leaks showing there.
Does anyone know for reason to showing different memory details for above 2 scenarios and which one is correct?
Also is there a way to programatically print the consumed memory by the app in the console?
Activity Monitor is a generally useless way to track memory growth. There are about a zillion different contributors to RPRVT, some of which are entirely non-intuitive. Activity Monitor can certainly be used to figure out "uh, oh, it is growing", but not much beyond that.
Use Instruments to track memory growth.
When you say "run in Debug mode", do you have anything configured like zombie tracking or allocation information tracking? That'll contribute to memory growth.
Beyond that, the Allocation Instrument will generally show you what is contributing to growth.
Also is there a way to programatically print the consumed memory by the app in the console?
An absolute number like this isn't very useful. That an app is growing is bad, but a raw number won't tell you why any more usefully than Activity Monitor.
Use Instruments. :)
When I run my iPhone app with "Leaks" (which has a section for Object Alloc), my app seems to be fine for memory allocation. However, when I run it with just the ObjectAlloc tool, the memory increases steadily as the app runs its main timer. (It is a timer based app). I'm not sure what to trust. I was just wondering if there are any issues with the ObjectAlloc tool that might pertain to me. Maybe something related to NSTImer? I'm running this on the device (not the simulator). Thanks.
Yes -- trust the tools. They are really quite accurate these days.
Leaks means an object or allocation for which the address of said object/allocation isn't stored anywhere else in your app. The memory is no longer accessible.
However, eliminating all leaks does not mean your app cannot grow without bound.
Unbounded growth can happen for a number of reasons. You might have a cache that keeps adding entries without pruning the least recently used entries. Or maybe a transaction log that is never truncated or flushed to the filesystem. Or you might keep loading new images into your application without throwing out the old.
Once you have eliminated all leaks, look at the output of ObjectAlloc and figure out where all that memory allocation is coming from. In particular, you'll want to figure out what your app is doing to trigger the allocations. The system frameworks won't spuriously cause continual growth without your application directly or indirectly asking for the resources to be consumed.
I'm afraid I introduced a memory leak or something to version 1.2 of my iPhone app. When I use 1.2 version I notice that my battery drains a lot quicker then with 1.1 version. For comparison, with 1.1 version the battery would last whole day and still have plenty of juice in the evening but with 1.2 I find that I have to plug it in mid afternoon.
Would a memory leak (or a lot of them) cause an increased battery drainage, or do I have something else going on?
The only interesting thing my app uses is AVAudioPlayer class to play some caf audio files. Other than that it's just couple of views with a table view.
I do call AudioSessionSetAcvie(false) in my applicationWillTerminate method, so I don't think it's the audio session that's causing this. I don't have to have my app active for the battery to get drained. It's enough to use it for a while and then exit. So I'm pretty sure I'm leaving something behind, I'm just not sure what.
I tried playing with Instruments tool, but it looks like you can't used with the app running on the device (for some reason my app stopped working in the Simulator)
Any ideas on how to go about finding what's causing the battery to drain?
Memory leaks will not cause increased battery usage. However, if a memory leak persists, eventually you will get a memory warning, and if you can't clean up enough memory, your application will be killed.
Increased battery utilization usually means something is causing your code to continue running. The best way to tackle this problem is to run your application under Instruments (with Sampler probably) and let it sit there in the state that you're confident it usually runs the battery down. Inspect the results of Sampler, and if you have code running, you'll be able to see the stack trace for it.
Hopefully once you've located what code is running, it will become apparent how to stop it.
Memory leaks won't cause increased battery usage, as Nilobject says.
I would try commenting out various areas of functionality, one at a time, to try to narrow down the area that is causing the problem. In your case, the first thing to try is obviously to remove the audio. If, once you've done that, battery usage is back to normal, you know where to look more deeply.
(for some reason my app stopped working in the Simulator)
I would fix that and use instruments to fix the performance bug. It's never a good idea to fix the difficult defect and leave the easy one.