iPad crash and probably related memory problems

Question

Hello folks,

I am porting PC game to iPad which has ton of graphic assets (over 250MB) and I am about half-way through. I didn't have iPad until now so I tested it only on simulator and everything was fine. But when I run it on device for first time, it crashed. All I got from console is

Program received signal:  “0”.

Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")

there is also warning at the startup which I didn't have on simulator and I don't know what it means or if it is related:

warning: Unable to read symbols for "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.2/Symbols/System/Library/AccessibilityBundles/AccessibilitySettingsLoader.bundle/AccessibilitySettingsLoader" (file not found).

I was able to determine that game crashes during loading of textures, most of the time at

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageData);

I use standard texture loading from samples and it worked perfectly so far. I estimate that at the time of crash I allocated few dozens mb worth of textures (I can't give you exact number right now).

I am no expert on anything, but it kinda seems like I run out of memory even though I don't get any memory warning (I check for them). Is it possible that I allocate more memory than I can at once and it crashes before it can issue memory warning? What surprises me most is that it doesn't throw exception or anything, it just dies on me. Even debugger doesn't tell me anything.

Any other ideas what can cause this crash?

And one last thing, I know this has been asked countless times before, but no one seems to have good answer to that. I will try asking anyway :) How many MB of memory can I get for my app? Is there some guaranteed minimum or theoretical (but still reachable :) ) maximum? Is there any way how to ensure I will have enough memory?

Game has a lot of fancy art graphics and I even though I use caching and I release textures that are currently not used, there still will be few dozens of mb of textures needed at one time. Is something like that even possible? How pro games handle lots of data? Any article would be greatly appreciated.

Answer 1

How many MB of memory can I get for my app? Is there some guaranteed minimum or theoretical (but still reachable :) ) maximum?

You can have 500 megs of free memory, but it may be unavailable due to fragmentation (program XYZ may have taken a space between 255 and 284 MB, for example). Since that, there is a question of memory, that is available for each malloc() called.

Nowadays it's a rare situation (kernel and garbage collectors are smart enough), but still - "out of memory" is "cannot load shared library *.dylib: cant find free space segment longing for N mbs".

Answer 2

Are you checking all your memory allocations and array bounds before any writes/loads?

Answer 3

The current model of iPad only has 256 MB available total on the system, and running Instruments on my device right now shows that it only has ~70 MB of that free for use after everything else is taken into consideration. Therefore, "a few dozens of MBs" might be pushing it when it comes to textures, depending on how large "a few" is.

If you are loading massive amounts of textures in one operation that is not on a background thread, you will not receive memory warnings simply because you'll jam up the main thread and prevent your application from receiving those warnings. You could load textures a few at a time, either on a background thread or by letting the run loop go to completion between each smaller texture load, and see if you can catch memory warnings at some point in the loading process.

Apple has a "Best Practices for Working with Texture Data" section in the OpenGL ES Programming Guide that I suggest you read. It has several tips for minimizing texture data size, prime among them being the use of PowerVR Texture Compression to massively reduce their in-memory size.