Previously released game, new Gideros version, crashes on Android device

PaulH

I released a game earlier this year (Ice Fishing Derby). Most users enjoy it, but a few get crashes I've been unable to explain or (until now) reproduce. Now I've updated to the latest Gideros Studio, tested again in the player, exported, rebuilt in Eclipse, and the app now crashes for me within a few seconds on my phone. Eclipse can run or debug the app in an emulator without any problems, just like it runs in the Gideros player, also works debugging or running on a tablet, but if I try to run or debug on the phone it runs for a few seconds and quits. I'm not seeing any warnings or errors on the LogCat.

Anyone have any suggestions for other ways to troubleshoot a crash happening only on a physical device?

PaulH

ar2rsawseen

There must be an error in log cat, sometimes when nothing appears there, I disconnect the device, close eclipse, open it again and connect device, relaunch the app, and it shows something in there

PaulH

I expected to see something, but I've restarted Eclipse, restarted the phone, tried numerous times, and the last thing from the LogCat is a list of libraries loaded, then MediaCmdReceiver saying "Thread started". Here's the LogCat from debugging:

10-23 08:50:51.906: I/dalvikvm(1753): Debugger is active
10-23 08:50:51.913: I/System.out(1753): Debugger has connected
10-23 08:50:51.913: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:52.121: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:52.320: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:52.515: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:52.718: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:52.924: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:53.124: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:53.326: I/System.out(1753): waiting for debugger to settle...
10-23 08:50:53.527: I/System.out(1753): debugger has settled (1446)
10-23 08:50:53.804: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/libgideros.so 0x40517578
10-23 08:50:53.913: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/libgideros.so 0x40517578
10-23 08:50:53.913: D/dalvikvm(1753): No JNI_OnLoad found in /data/data/com.pishtech.mifd/lib/libgideros.so 0x40517578, skipping init
10-23 08:50:53.913: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/libluasocket.so 0x40517578
10-23 08:50:53.929: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/libluasocket.so 0x40517578
10-23 08:50:53.929: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/liblfs.so 0x40517578
10-23 08:50:53.937: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/liblfs.so 0x40517578
10-23 08:50:53.937: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/libggooglebilling.so 0x40517578
10-23 08:50:53.953: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/libggooglebilling.so 0x40517578
10-23 08:50:53.953: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/liblsqlite3.so 0x40517578
10-23 08:50:53.960: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/liblsqlite3.so 0x40517578
10-23 08:50:53.968: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/libjson.so 0x40517578
10-23 08:50:53.968: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/libjson.so 0x40517578
10-23 08:50:53.976: D/dalvikvm(1753): Trying to load lib /data/data/com.pishtech.mifd/lib/libbitop.so 0x40517578
10-23 08:50:53.976: D/dalvikvm(1753): Added shared lib /data/data/com.pishtech.mifd/lib/libbitop.so 0x40517578
10-23 08:50:55.015: D/Gideros_Java(1753): externalDir: /mnt/sdcard
10-23 08:50:55.015: D/Gideros_Java(1753): internalDir: /data/data/com.pishtech.mifd/files
10-23 08:50:55.015: D/Gideros_Java(1753): cacheDir: /data/data/com.pishtech.mifd/cache
10-23 08:50:55.124: D/libEGL(1753): loaded /system/lib/egl/libGLES_android.so
10-23 08:50:55.124: D/libEGL(1753): loaded /system/lib/egl/libEGL_POWERVR_SGX530_125.so
10-23 08:50:55.148: D/libEGL(1753): loaded /system/lib/egl/libGLESv1_CM_POWERVR_SGX530_125.so
10-23 08:50:55.171: D/libEGL(1753): loaded /system/lib/egl/libGLESv2_POWERVR_SGX530_125.so
10-23 08:51:04.812: D/MediaCmdReceiver(1753): Connected to server
10-23 08:51:04.851: D/MediaCmdReceiver(1753): Thread started
10-23 08:51:05.093: D/MediaCmdReceiver(1753): close
10-23 08:51:05.156: D/MediaCmdReceiver(1753): Connected to server
10-23 08:51:05.171: D/MediaCmdReceiver(1753): Thread started

After a few seconds, probably when the game tries to show its main menu, the game dies, with no more entries in the LogCat.

Really baffled... I've tried adding some file IO to log the progress as screens load, etc., calling a function to append a message to a file, hoping to at least narrow down what part of the code it's in when it quits. I'm logging steps with this code:

local file = io.open("|D|mifdts.txt", "a")
if (file~=nil) then
file:write(msg .. "\n")
file:close()
end

The log file doesn't appear to anywhere on the phone, either in system memory or on the SD card. I've spent quite a bit of time trying to get that working without success, though I know others have had issues with file IO.

Any other ideas?

Paul

john26

Maybe try creating a stand alone APK and installing it manually on the phone. Thus rule out this being due to Eclipse.

Does it crash on every Android phone or just one?

PaulH

I've tried the manual APK installation and I get the same crash. Based on user reviews it seems to crash on a handful of models. That never included mine until this update. It's fine on a Galaxy Tab, but seems to crash at least on the Droid X and X2.

ar2rsawseen

So let me get this straight
the app works on Gideros player (on device) but fails as exported apk and it started happening after Gideros upgrade?

Did you do full export from Gideros in the fresh clean directory? Maybe some old gideros files from previous version interfere with the current exported app.

PaulH

It works in the Gideros player on Windows. I wasn't aware the player could run on the device. I've only ever produced the APK by exporting the Android project and building in Eclipse. The app failed on some devices but none of mine in the past, but now it's crashing at the same point on my phone (Droid X), though still working fine on my tablet (Galaxy Tab).

I'll try exporting to a fresh directory to try to rule out stray files.

PaulH

ar2rsawseen

if it works on one Android device and does not work on another, then probably the fault is not in older files.
I also see from logcat that you do not use any external plugin (only the ones bundled with the project), is that right?

PaulH

That's correct. I experimented with using the AdMob plugin, but current there are no added libraries. Next I'll try moving the project to my laptop and try to debug on the player on the phone over wifi.

PaulH

Move project to laptop, testing on Gideros player on the phone in question, and I get the crash. I was using print statements to try to narrow it down, and it seemed like it could be related to some timers I'm using. I put up a "loading" screen and use a timer to trigger the actual loading of all the scenes, so the system will take over and get the loading screen to display. Then the function called by the timer does the rest of the loading. Somewhere along the process, and at a slightly different point each time I run it, the "print" statements stop working and nothing further gets to the output. Clearly more code is getting executed, though. My menu music starts before it loads all the graphics and I hear it start, but the print statements around starting the music don't show up in the output window.

Anybody have any ideas why print statements might not show up?

PaulH

I've determined things break down when the code tries to pre-load all the scenes. For each scene (shopping for tackle, cutting a hole in the ice, fishing, etc.) I have a lua file defining the scene. Each scene extends the sprite class and has a full screen sprite for the background, and various bitmaps that get added as children of the main sprite to complete and animate the scene. So by loading all the scenes, I'm loading all the game graphics into memory at once. The idea was to minimize the time transitioning between scenes. I've found that if I load only the first couple of scenes the crash doesn't happen, until of course I try to move to one of those scenes that hasn't been loaded. If I add code to load them only when they're needed I get the crash on about the third scene. It seems that if the code gets far enough to trigger the crash, the queue of print statements waiting to get handled (shown on the output window) get lost.

I suspect all this means the device is simply running out of memory. I could overhaul the code to keep only the current scene in memory, at the cost of much slower scene transitions. Before starting the app I see free memory about twice the size of the app, but with overhead perhaps that's not enough. Even if I shut down all apps and do a memory cleanup immediately before launching the app I get the same crash, and briefly see system memory quite low after the crash before it shoots back up.

I think I have to conclude that I need to take a careful look at memory management throughout the app.

Or has anybody seen anything similar that was caused by something else?

ar2rsawseen

on mobile phones, especially with higher res graphics its very easy to hit the ceiling.
thats why SceneManager was made with the idea of disposing previous scene and moving to another.
Well as last resort, you could save the most common scene (like start scene) in the memory, but dispose of other scenes when moving to the next ones