views:

336

answers:

2

I have a Cocos2d/openGL iPhone game. It's a universal app and I'm dealing with an occasional but nasty error on the iPad.

We are loading a lot of textures up front (3 2048x2048 textures). I'm working on reducing this up front load, but what worries me is I really don't understand the root cause of this crash that permanently breaks the app.

This is the deal: 1. App works fine for hundreds of plays on the iPad 2. Eventually (I'm guessing due to other programs using up some memory and not letting go or whatever) the app starts crashing on startup. It just closes again in the middle of loading. 3. The App will now never work again on that iPad, closing immediately every time, until the iPad is restarted.

Obviously my app is demanding too much memory up front to work reliably every time, I get that. What I don't get is why when it fails once, it has failed forever until the iPad is restarted. Can anyone explain what is going on here?

EDIT: forgot to add

organizer crash lags just say low memory, like this every time (I changed my app name to MyAppName below). Again, I know it's low memory, but why does it stay low memory until restart?:

Incident Identifier: E7A2507C-3FB1-4E3B-B315-09F094236541
CrashReporter Key:   0fda9d667f2c6073f20a76809aa25438b6854d15
OS Version:          iPhone OS 3.2 (7B367)
Date:                2010-04-30 16:59:44 -0400

Free pages:        437
Wired pages:       17228
Purgeable pages:   0
Largest process:   MyAppName

Processes
         Name                 UUID                    Count resident pages
       MyAppName <6307ce41802850944baa78d29224fa7f>   22385 (jettisoned) (active)
    mediaserverd <ea8bac28b06fe3980fdd44b5caceb563>     242
      DTMobileIS <a0f651e43881e66f50f8a95abea72921>    5826
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      67
    syslog_relay <4ceaed776d2df957fa130712f4ef21d0>      66
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      67
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e>      67
            afcd <4f3c9566e33b4463f05603d990584e5d>      72
            ptpd <83de0f774bd6553d513ae9e19b0f9b56>     181
         syslogd <66247e305d5c0bf6f1ce1cc950653263>      81
             lsd <a4d852c1c8da2b3d231bdc90887b52ba>     130
            iapd <a8534cbde4b90ad5915dd26ab03ff3e3>     204
         notifyd <5e9d5bee7c3eae1c8b494c79eb11406e>      71
        BTServer <64e4a6ea6b1240db2331e05a29caa862>     108
      CommCenter <97bf297944ac4bde19bcee96dd23bd5f>     181
     SpringBoard <c7a5904c12db7b14334a4edaa4cabaa9>    5339 (active)
         configd <aca9fa3380322669164fd6b1a3864300>     373
   fairplayd.K48 <2d997ffca1a568f9c5400ac32d8f0782>      84
       locationd <dd1ea88105c62173908ce767db5c4d37>     599
   mDNSResponder <820560222d47a1f2a0dce98a7f8a9721>     108
       lockdownd <497fd54c79a680bf29f5d9320f514613>     303
MobileStorageMou <c277b79c2157c4dc5cfc5c3ca35bd5f2>      69
         launchd <66972eee4d865c4383b33d985d22994b>      98

**End**

A: 

Just a guess with the limited information, but your description of the steps to reproduce sounds like you are allocating memory outside of your application space, or more likely using a resource out side of your application space that is not being released upon termination of your application. This scenario seems the most likely place that you should begin looking. Try reducing your applications functionality to make the track down easier.

Kenny
+2  A: 

My guess is that on a freshly booted iPad, you happen to have just enough free RAM to load all your textures. Then, at some point in time, other processes on the iPad (e.g. Mail) start consuming a little more memory, therefore not leaving enough left for your app.

Your crash log shows that your app was using 22385 pages of memory, which is about 87 megs (assuming that page size is the same on the iPad and iPhone, which is 4k on iPhone).

Also, it shows that SpringBoard isusing 5339 pages of memory, which is about 20 megs. I don't know about OpenGL, but I've heard that with Core Animation, whenever images are set as contents of a CALayer, the uncompressed image data is allocated in shared memory managed by SpringBoard.

All in all, 87 + 20 megs is a lot of memory for a device that has 256 megs of RAM and no swap file...

Pascal Bourque