iPhone Object Allocation, GeneralBlock-24 & GeneralBlock-48 - iphone

I have 3 memory leaks after the launch of the iPhone application. These remain constant no matter what I do in the App (no more leaks).
My Net Object Allocation keeps growing. There are two blocks in particular, GeneralBlock-24 & GeneralBlock-48.
Block-48 gets specially bad as the program is being used, taking Megabytes of memory. The Library that seems to be allocating the objects in both blocks is QuartzCore.
The App had a reference to the QuartzCore framework, but I have eliminated all references to it.
p.s.: this is all on device, not the simulator

Found it! When running it on the simulator with Instruments the GeneralBlocks are reported as a single GeneralBlock-0. Searching through the web it seems that there is a bug in instruments objectAlloc reporting and QuartzCore.
So I just added a Memory Monitor instrument and saw that even though my Object Allocation kept growing non-stop, my Real Memory remained flat (well, moving up/down within half a MB)
I hope it's useful info to others, I spent a day searching for GeneralBlock-24 & 48 trying to figure it out until deciding to run it in the simulator just for the heck of it

Related

CJPEGCreateImageDataWithData allocating a lot of unreleased memory

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.

iPhone game is crashing after memory warning with message " Data Formatters temporarily unavailable, will re-try after a 'continue' "

I am in the final stage of developing an iPhone game and I am dealing with a crash that appears to be memory related.
It happens only on the device when I load a game level several times (10 to 15 times). I get some memory warnings around the 8th time and if I keep loading the same level it finally crashes with this message on the console:
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library
"/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
Some goolge search told me this message usually means the app has run out of memory.
I ran the app under instruments but it didn't detect any memory leaks and the total allocation remained around 1,5Mb (both live and overall bytes) reaching 5,4Mb for a fraction of a second everytime I loaded a level. This doesn't seem a lot since a leaky test app didn't crash before allocating more than 30Mb on the same device (iPhone 3GS). I am new to instruments so maybe I am missing something.
I ve been struggling with this bug for days now and I would be really thankful if someone could point me in the right direction.
Check in Instruments the Activity Monitor instrument. You'll find the correct amount of RAM you are consuming at any given time. The Allocations instrument is not really an indicator of RAM usage. It will however help in finding things that have been allocated and not released. Use heapshots in Allocations to find out where things are being leaked.
http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/
Yes, your searching was right "this message usually means the app has run out of memory"
Please read memory management documentation from apple and release your objects properly if where you getting memory leaks.It will reducing memory warnings as well as your code will work fine.
When you allocating simultaneously objects when new level loading it will indirectly premises you allocating objects but you not able to delloc properly, it means that you creating new memory for new object but still old object is in memory. After this scenario why not you got memory warning?

How do I see how much memory my iPhone app is using?

How much real memory should my iphone app be using? What's going too high?
Keeping an eye on -(void)applicationDidReceiveMemoryWarning:(UIApplication *)application is definitely important, but if this is game, chances are the assets (notably textures presently on screen) can't simply be deallocated when that warning is received.
If you're a bit on the high side (20 MB +) I would recommend doing a bit of testing. Using Instruments and the Object Allocation tool (Run > Run with Performance Tool > Object Allocations) you can monitor how large your memory footprint gets. Then, try running Safari and fill the pages, then a few games and whatever else you can to get the memory higher, and see how your app performs.
In my testing for a recent release, 24 MB seemed to be pretty safe, and is a number I've heard elsewhere. Once you get above 30 or so MB, chances are your users will start having rare crashes (which happens to be the case for us, verified by crash reports). The higher you go, the more crashes users will see. There's no specific limit though, for the sake of testing I've pushed my app on an iPhone 3G up to 70 MB before, it just isn't likely to work for most, nor for long.
Requesting on the iTunes page that users restart their devices can help, though there's no guarantees it'll be effective.
Also, this is all assuming devices prior to the 3GS / 3rd Gen iPod Touch. If the app merely runs on an older device, it should have no problem on the newer ones (which have twice as much ram, 256 MB).
I think available memory may depend on several factors such as device model, how long it has not been rebooted etc.
You should not rely on some fixed values but instead try to use as little memory as possible and implement -(void)applicationDidReceiveMemoryWarning:(UIApplication *)application in your application delegate and/or -didReceiveMemoryWarning in your view controllers to handle low memory warnings there and free unused memory.

Do I trust ObjectAlloc or Leaks for analyzing my iPhone app?

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.

Xcode Instruments: peak RAM of iPhone apps running in Simulator?

Is Activity Monitor (a.k.a. Memory Monitor) the only tool in Xcode Instruments that can measure the total app RAM usage of an iPhone app running in Simulator? Just that line showing momentary wired RAM?
And how accurate is that versus iPhone hardware, especially given OSX paging i/o to VM?
I'm seeing 7-8MB wired RAM figures for just the default Xcode iPhone project templates (other than OpenGL) compiled and running. At the same time Object Allocations shows well under 1MB for all objects.
Nope, there's a much better way to do it.
Go to the Run menu and select Run with Performance Tool then Object Allocations.
This will start Instruments and will show RAM usage. It's also useful for detecting memory leaks if you choose Leaks instead of Object Allocations.
I would agree, since the Simulator is just an "API simulator", the behavior you see is going to be at least somewhat dependent how OS X manages memory. And the restrictions are obviously different, for example you can exceed 128 MB of ram, or even 256 MB, which obviously isn't possible on any current iPhone or iPod Touch (at least, as of this writing...).
I've still found it useful in OpenGL for making sure textures and other items are properly deallocated, but beyond that, it's just a rough guideline.
However, if you want to see memory usage on device, there's a simple enough solution. Just target Device in Xcode, and go to Run > Run with Performance Tool > Object Allocations, then the build will be sent to the device and the Object Allocations tool will pop up next to Xcode and show on device memory usage.