Yep, I know there might be many reasons after coding several 10k lines which perform many animations in my game but after trying a lot of debugging/optimizing my code, I found no solution to the following problem:
The Codea runtime quits my app after some time.
(It seems not Codea itself that crashes, it just quits my running app in Codea without any errors given)
My developing environment details:
• I’m developing on an iPad Air2 using BBEdit on OSX 10.9.5 via copy/paste to Air Code.
• This happens since around last quarter of 2015 when I updated from iOS 8.x to 9.x and Codea was also updated to the recent version ( 2.3.2(61) ). It never happened before these updates.
• No, I didn’t verify if the problem goes away after compiling with recent Xcode, because I have not updated to latest El Capitan by now.
After hardly verifying my code for stupid mistakes, I’m simply lost now and hope to get some ideas from you guys:
• Did I missed some kind of manual garbage collection I should include in my code? (collectgarbage(“count”) returns always only +/- 1MB in my app)
• Could it be iOS 9.x which stops it because of power consumption? (I optimized my code carefully for this)
• Does anyone else has similar experiences?
• Any ideas whatever to try else?
@Ignaz: Thanks for your response.
If you read carefully what I wrote above, you’ll find out that it’s not a code problem in my app. The problem appears since the mentioned updates.
Thanks anyway,
Heiko
To further refine: The quitting occurs under same app running conditions unexpectedly between 30 minutes and several hours. This makes it hard to track down.
How can you be so sure? I know it’s tempting to blame the OS, the runtime etc, but 99% of the time, it’s your own code.
I would put it in Xcode, deploy it to an iPad, run it while tethered to the Mac, and see whether the Xcode diagnostics tab tells you anything.
Do people really play iPad games for hours at a time tho? I’d say that as long as my position in the game is frequently saved, I wouldn’t mind if an iPad app crashed after an hour’s use. If I have to deal with an interruption, a FaceTime call or whatever, you can’t count on the game’s state persisting, so progress-saving is important.
@yojimbo2000: As I wrote above, I can be sure because it happens since the updates. Also I wrote that it’s quitting between 30 minutes and several hours, which is not usual behavior for an app. And yes, of course my app saves the game states between levels. Again I wrote above that I currently can’t update to latest Xcode to test by now and it wouldn’t solve the quitting inside Codea anyhow. Thanks anyway for your comment.
One suggestion is to save the amount of memory used every so many minutes. Then when your app quits, you can see the amount of memory that was last used. If it’s a high amount, then you know you have a memory leak. If not, then you can look for something else.
@dave1707: Thanks for your suggestion. It can’t be a memory leak. As I stated above my app uses just around 1MB. I’m already constantly reading the used memory and show it onscreen. Also even while a lot of animations happen, my code is optimized to rarely go below 55fps.
@HeiKoDea Can you list the things you do. Do you use meshes or recursion or graphics, etc. It’s hard to say what might be happening when we don’t know what you’re doing. You may be only using 1MB while your app is running, but it might spike just before it crashes. Since you know your upper memory limit, maybe you can save the size of memory used anytime it exceeds your upper limit.
EDIT: By graphics, I mean stuff like setContext or large images, etc.
@HeiKoDea you can be sure that something has changed since the update. However, that does not mean that it is a bug in the update. It could still be a bug in your code which has exercised a perfectly legit change in Codea. The only way to be sure, unfortunately, appears to be to find a way to cause it quickly and every time, that is consistent with what the more complex program is doing.
I had hoped that people knew some things one could do that might crash Codea, so that I could look into my code to see if I was doing any of them. Unfortunately, the discussion hasn’t provided that information.
There used to be 1 or 2 things that reliably caused Codea to bail, but they’ve gradually been patched. Eg pointing the camera along the same axis as its up axis. I think that no longer makes Codea crash (but still shouldn’t be done).
@dave1707: There are no recursions nor meshes in my code. I use prepared .png graphics stored inside the project and animate them mostly with the juice library. The only .jpg is for filling the background, which is always animated by the acceleration sensor to have a kind of parallax effect. Most of the quitting occurs when the app is idle and has nearly nothing to work inside the draw() loop or anywhere else. Therefore a spike is very unlikely but I’ll try your suggestion.
@RonJeffries: I fully agree. I think the only way to find out is to write a small test app and let it run for a while. I’ll let you know if I find something in the next days.
• It’s not Codea that crashes therefore I couldn’t find any messages inside the iOS system logs. It’s my app running inside Codea that jumps after a while to the iOS home screen. If I double click the home button the last screen of my app is shown in the list. Tapping it immediately quits the app showing the Codea home screen. After that I can use Codea without restarting and without errors.
• Usually I don’t run any other apps while in Codea. The only exception is sometimes the SystemMonitor app, which never showed any unusual memory/CPU/GPU usage.
• I don’t use any network connection code in my app.
• The app is all about plane ol’ 2D animated graphics. No rocket science.
Ok, here’s a simple code example which crashes Codea in between 5 to 30 minutes:
function setup()
displayMode(FULLSCREEN)
bgImg = readImage("Cargo Bot:Background Fade")
tile = {
readImage("Cargo Bot:Crate Blue 1"),
readImage("Cargo Bot:Crate Green 1"),
readImage("Cargo Bot:Crate Red 1"),
readImage("Cargo Bot:Crate Yellow 1")
}
end
function draw()
background(40, 40, 50)
sprite(bgImg, WIDTH/2, HEIGHT/2, WIDTH, HEIGHT)
for i = 1, 1000 do
sprite(tile[math.random(1, 4)], math.random(1, WIDTH), math.random(1, HEIGHT))
end
end
If you check memory usage, eg with collectgarbage("count"), you’ll see it just keeps climbing as the program runs, and so running out of memory is the most likely cause of your problem.
If you run collectgarbage(), the memory use (on my iPad) drops to about 400, before starting to climb again. So if you collect garbage (say) every minute, that should be enough to restrict memory usage and avoid the crashes.