Second Generation iPad Mini Crash - EXC_BAD_ACCESS (code=1, address=0xcd56060)

[douglascavanaugh]

Have an app that was developed for both low res and high res iOS and Android devices.  Using TexturePacker to create the sprite sheets (display.newImageRect(…)) using 75% (@2x) and 50% scaling variants (75% is so that I can keep the total app memory down because it’s pushing 400MB as it is).  When I test the app in the Simulator,  I’m outputting both the “memory” and “texture memory” in the console via:

function printMemory(event) collectgarbage( "collect" ); local memUsage\_str = string.format( "MEMORY = %.3f KB", collectgarbage( "count" ) ); print( memUsage\_str, "TEXTURE = "..(system.getInfo("textureMemoryUsed") / (1024 \* 1024) ).. " MB" ); end timer.performWithDelay(1000,printMemory,-1);

and it runs flawlessly on ALL devices in the Simulator.  No surprise there.

So then I go over to xCode, plug an iPad Air 2 device into my Mac and compile/run so that I can monitor the metrics.  What’s nice is that I can monitor the ACTUAL CPU/Memory/Energy Impact/Disk/Network/FPS (Frames Per Second) in the Debug Navigator Dashboard for the device I want to run it on.  Absolutely love the dashboard view and it certainly helps with how an app runs on a particular iOS device.  As is with the Simulator, runs flawlessly on the iPad Air 2 along with the iPhone 6 plus.  CPU never goes above 20% (with everything that I have running such as Textures/CBEfx/Animations etc…) and total Memory usage stays around 280 MB.

Now when I plug in a second generation iPad mini (2012), build (in xCode) and run my app so as to monitor the metrics, CPU ranges between 6% and 100% (with everything running as indicated above) and Memory stays around 190 to 230 MB (as it should be lower based upon the fact that I’m not using the @2x images).

However, it crashes on the second gen iPad mini.  Now taking for granted that the iPad Air 2 has over 1GB of Memory and the iPad mini has 500MB of Memory, there’s not much room to play on the iPad mini and with the potential of other apps opened and/or processes running (which is an assumption we as developers have to make), the 190 to 230 MB is pushing it.  In my test on the iPad mini, I make sure that nothing else is running  on the device, however, when I build and run the app in xCode and view the Memory usage in the Debug Navigator, there seems to be an equal amount of memory (if not more) being consumed via “other processes.”  I don’t want to delve into the “what could that be if nothing else is running,” but for the sake of your getting a visual of what I’m seeing, I point it out.

Getting to the purpose of my post, as I said, the app crashes on the iPad mini.  BTW, If anyone is wondering, yes, I get the “Received Memory warnings.” in xCode’s console.  So when it finally crashes (quits), nothing is displayed in the console other than those “Received Memory warnings…” but it does show the following error message in the Debug Navigator window from the main.mm file:

// // main.mm // // Copyright (c) 2016 A Complete Teacher. All rights reserved. // #import "CoronaApplicationMain.h" #import "AppCoronaDelegate.h" int main(int argc, char \*argv[]) { @autoreleasepool { CoronaApplicationMain( argc, argv, [AppCoronaDelegate class] ); } return 0; }

CoronaApplicationMain( argc, argv, [AppCoronaDelegate class] ); --> Thread 1: EXC_BAD_ACCESS (code=1, address=0xcd56060).  See included image.

On all high res devices, it runs flawlessly, however, it does eventually quit on the low res devices (both iOS and Android).  Anyone have any insight?

Correction, iPad mini Second Gen…

[Lerg]

You said iPad Mini 2nd gen, but your console says “iPad 2,5”, which is first gen. First gen has 512MB of RAM and it is identical to iPad 2, so on iPad 2 your app will also crash.

By the looks of it you indeed ran out of free memory on your device and your app simply crashes because it can no longer allocate memory.

200…250 MB of RAM for the app seems to be the right amount. The other half is used by the iOS itself.

Regarding your assets, are @2x assets for iPad retina and normal assets for low res iPad? If your @2x are for all iPads and normal for low res iPhones, it’s not surprising that your iPad tries to use much RAM.

If that’s the case and your iPad uses hires assets, you can force it to use low res assets in config.lua.

[douglascavanaugh]

Thanks for your input Lerg!  Yes I surmised that was the case, I just wanted a confirmation from Corona re; the EXC_BAD_ACCESS (code=1, address=0xcd56060) error and that it wasn’t something else.  And yes, I have the imageSuffix for @2x set at 1.3 aspect ratio in config.lua so all the lower res devices use the lower res images.  Seems I may have to reduce the lower res images to something less than 50%…

[douglascavanaugh]

Update…  No longer a memory issue as I’ve managed to reduce the memory usage down to 50MB(ish) (was near 200)…  I built with version 2015.2799 and tested on both the iPad 1 and Air 2 with no problems.  I also tested on a Samsung Note 3 and a 2012 Kindle Fire with no problems (both platforms using low res devices and high res devices) so that eliminates the problem (or so I thought).

However, I did the final build (again 2015.2799), for distribution, uploaded to apple, then via testflight, download to the iPad 1 (and Air 2 which tested fine) to do one last test and it crashed again on the iPad 1 (random spots).

Per the attached screen captures, you can see that all metrics are way below any clip levels.  However, after drilling down under Thread 1 (left column), I saw something that caught my eye…  “PhysicsJoint::FInalizer(lua…” and  "Thread 1:EXC_BAD_ACCESS (code=1, address=0x3e7c200).  Now before I make any assumptions about a physics error specifically related to a first gen iPad, this works flawlessly on iPad Air 2, Samsung Note 3 AND a 2012 Kindle Fire 7,” so, can anyone shed some light on this???

[Lerg]

Do you use physics.pause() in your app? Also try to remove all joints manually before removing display objects with them. Maybe for some reason iPad can’t keep up with it.
Or you can just ignore iPad 1st gen since it is almost never used to install new software.

[douglascavanaugh]

What do you mean by your statement:  “Or you can just ignore iPad 1st gen since it is almost never used to install new software.”?

No re; the physics.pause()…  Just start/stop and less than a handful of weld joints per scene.

I put the remove display ( weld var name ) prior to removing the display objects they were associated with and all that does is causes the app to crash “consistently” on any scene that has the weld join calls… when the remove display (weld var name) is after the removed objects, it crashes randomly.

Interestingly, immediately after resolving the RAM overhead issue, I built and tested the app and it work flawlessly on the older iPad… Yet when I built the app within the past couple of days, this behavior resurfaced???  And no I did not update Corona since resolving the RAM issue…

[douglascavanaugh]

Lerg, these failures occur on the iPhone 6 and 6s as well.

[douglascavanaugh]

Well, I’ve narrowed it down to the following:

I have 5 joints (2 legs, 2 arms and a head) attached to a body.  When the scene starts, the body is transitioned onto the scene and when the transition is complete, I have a listener that puts the body into motion (i.e., anti-gravity simulating a floating state):

------------------------------------------------------------------ -- BODY ANTI-GRAVITY -- function to float body function constantForce( self, event )     -- simulate anti-gravity     if ( self.id == "body" ) then         -- bounce body as if floating         self.angle = ( self.angle -0.03 );         self.y = -self.amp\*math.sin(self.angle)+self.y;     end     return true;          end

Apparently the iPad cannot deal with the joints along with the motion and that is what’s causing the crashes.  I should also mention that I have emitters on each limb (think Iron Man).  I have another scene where there’s a similar scenario, but I rotate the body and as well, it causes the app to crash.  All the other scene’s that have joints but no movement associated, do not cause the app to crash…on the first gen iPad…

Guess I’ll have to get the “platformVersion” and include logic…  Has anyone used that successfully to detect which iPad version the user is running?

[rob]

The system.getInfo( “architectureInfo” ) API (https://docs.coronalabs.com/api/library/system/getInfo.html#architectureinfo) will return strings like iPhone 6,1, iPad 4,2.

This web page, outlines what the values mean:  https://www.theiphonewiki.com/wiki/Models

From that you should be able to derive a test to determine were to cut features.

Rob

[douglascavanaugh]

Thank you Lerg and Rob!  Cheers!

[Lerg]

You said iPad Mini 2nd gen, but your console says “iPad 2,5”, which is first gen. First gen has 512MB of RAM and it is identical to iPad 2, so on iPad 2 your app will also crash.

By the looks of it you indeed ran out of free memory on your device and your app simply crashes because it can no longer allocate memory.

200…250 MB of RAM for the app seems to be the right amount. The other half is used by the iOS itself.

Regarding your assets, are @2x assets for iPad retina and normal assets for low res iPad? If your @2x are for all iPads and normal for low res iPhones, it’s not surprising that your iPad tries to use much RAM.

If that’s the case and your iPad uses hires assets, you can force it to use low res assets in config.lua.

[douglascavanaugh]

Thanks for your input Lerg!  Yes I surmised that was the case, I just wanted a confirmation from Corona re; the EXC_BAD_ACCESS (code=1, address=0xcd56060) error and that it wasn’t something else.  And yes, I have the imageSuffix for @2x set at 1.3 aspect ratio in config.lua so all the lower res devices use the lower res images.  Seems I may have to reduce the lower res images to something less than 50%…

[douglascavanaugh]

Update…  No longer a memory issue as I’ve managed to reduce the memory usage down to 50MB(ish) (was near 200)…  I built with version 2015.2799 and tested on both the iPad 1 and Air 2 with no problems.  I also tested on a Samsung Note 3 and a 2012 Kindle Fire with no problems (both platforms using low res devices and high res devices) so that eliminates the problem (or so I thought).

However, I did the final build (again 2015.2799), for distribution, uploaded to apple, then via testflight, download to the iPad 1 (and Air 2 which tested fine) to do one last test and it crashed again on the iPad 1 (random spots).

Per the attached screen captures, you can see that all metrics are way below any clip levels.  However, after drilling down under Thread 1 (left column), I saw something that caught my eye…  “PhysicsJoint::FInalizer(lua…” and  "Thread 1:EXC_BAD_ACCESS (code=1, address=0x3e7c200).  Now before I make any assumptions about a physics error specifically related to a first gen iPad, this works flawlessly on iPad Air 2, Samsung Note 3 AND a 2012 Kindle Fire 7,” so, can anyone shed some light on this???

[Lerg]

Do you use physics.pause() in your app? Also try to remove all joints manually before removing display objects with them. Maybe for some reason iPad can’t keep up with it.
Or you can just ignore iPad 1st gen since it is almost never used to install new software.

[douglascavanaugh]

What do you mean by your statement:  “Or you can just ignore iPad 1st gen since it is almost never used to install new software.”?

No re; the physics.pause()…  Just start/stop and less than a handful of weld joints per scene.

I put the remove display ( weld var name ) prior to removing the display objects they were associated with and all that does is causes the app to crash “consistently” on any scene that has the weld join calls… when the remove display (weld var name) is after the removed objects, it crashes randomly.

Interestingly, immediately after resolving the RAM overhead issue, I built and tested the app and it work flawlessly on the older iPad… Yet when I built the app within the past couple of days, this behavior resurfaced???  And no I did not update Corona since resolving the RAM issue…

[douglascavanaugh]

Lerg, these failures occur on the iPhone 6 and 6s as well.

[douglascavanaugh]

Well, I’ve narrowed it down to the following:

I have 5 joints (2 legs, 2 arms and a head) attached to a body.  When the scene starts, the body is transitioned onto the scene and when the transition is complete, I have a listener that puts the body into motion (i.e., anti-gravity simulating a floating state):

------------------------------------------------------------------ -- BODY ANTI-GRAVITY -- function to float body function constantForce( self, event )     -- simulate anti-gravity     if ( self.id == "body" ) then         -- bounce body as if floating         self.angle = ( self.angle -0.03 );         self.y = -self.amp\*math.sin(self.angle)+self.y;     end     return true;          end

Apparently the iPad cannot deal with the joints along with the motion and that is what’s causing the crashes.  I should also mention that I have emitters on each limb (think Iron Man).  I have another scene where there’s a similar scenario, but I rotate the body and as well, it causes the app to crash.  All the other scene’s that have joints but no movement associated, do not cause the app to crash…on the first gen iPad…

Guess I’ll have to get the “platformVersion” and include logic…  Has anyone used that successfully to detect which iPad version the user is running?

[rob]

The system.getInfo( “architectureInfo” ) API (https://docs.coronalabs.com/api/library/system/getInfo.html#architectureinfo) will return strings like iPhone 6,1, iPad 4,2.

This web page, outlines what the values mean:  https://www.theiphonewiki.com/wiki/Models

From that you should be able to derive a test to determine were to cut features.

Rob

[douglascavanaugh]

Thank you Lerg and Rob!  Cheers!