views:

84

answers:

3

I'm seeing my app being killed by iOS with an out of memory message, however, while tracing the progress of the app in the Allocations Instrument, I see lots of mallocs that seem to be occurring outside of the code I've written.

I'm not seeing any leaks being caught, so I assume these allocations are supposed to be there. Thing is, because I'm not sure about why they have been allocated, I'm not sure what I can do to optimize the app and prevent the OS from jettisoning my app.

Does anyone know why the memory is being allocated, or is there any way for me to find out?

Here are a couple of shots from Instruments showing the mallocs. In the second shot, all of the allocations have the same stack trace.

One

Two

EDIT

I' displaying a single large image as the UIView background (1024x768), then overlaying a smaller (600px square) UIView with some custom drawing and a third UIView (550px square) over the top of those that contains two 550px square images overlayed.

I'm guessing that this is not appropriate, and there is probably a better way of achieving the composition of views I need for the app to work.

Should this be possible on the iPad?

+1  A: 

I think there's not really much information to go on here - if you add a bit more information about what this view in your app is doing you might get some more informed suggestions.

From the screenshot, it would appears large blocks are being allocated to display an image.

Given that I'd hazard a guess that either you're trying to display some very large images, or you UIView is large, or you have more UIViews in memory that you need to display the current screen.

I guess the easiest way to track down exactly where they're coming from would be to disable the part of the application you suspect then run again and see if the allocations still occur.

EDIT

Are all the images the same size as you're displaying them? (ie. are you trying to display a 5M photo as the 1024x768 background?) If not you probably need to scale them down to the size you are display them, or at least closer.

If you're not needing transparency, make sure to make all the views opaque.

JosephH
This is exactly what I'm trying to do - I've updated my question with more details.
Mr. Matt
and I've updated my answer with the things that immediately spring to mind - hopefully other folks with come up with other ideas. It's probably worth making your question summary more specific now you know the cause.
JosephH
The images are all the correct size, and I do need transparency. Looking at the stack trace, are the CA: entries core animation?
Mr. Matt
Mr. Matt: Sure looks like it. They are in QuartzCore, the same framework as Core Animation's public API. You can run nm on the QuartzCore executable and pipe the output to c++filt to test that theory.
Peter Hosey
A: 

Mallocs can occur inside of other API's that your app calls (such as loading images, views, playing long sounds, etc.) You can try changing the size of your images, views, sounds and other objects by various amounts as a test, and see if the size of the malloc'd memory changes track one of the changes that you've made.

hotpaw2
+1  A: 

I figured out the source of the problem - I was using

[UIImage imageNamed:@'Someimage']

to load in my images. This, as I'm sure many people are aware, caches the image data. I had enough images of sufficient size to cause my app to be jettisoned.

The problem was apparent not because of the size of the image but because of both the size and number of images I was using. The lesson here is be careful with [UIImage imageNamed:].

Thanks for all of the help, chaps!

Mr. Matt