Android Is there a way to debug and fix SIGSEGV, SEGV_MAPERR related crashes in libyoyo.so?

[SnoutUp]

Hello,

as far as I know, these things have been haunting Android releases forever and with recent crash reporting changes in Google Play (automatic reports added to the manual ones), they got more and more painful to see.

Problem is, that stack traces don't give much information and leaves me wonder, if it's my code that is wrong or GM.

Here are few examples. If you've got a game published on Google Play, you probably already familiar with one or two of these.

backtrace:
  native: pc 00000000002ca748  /data/app-lib/com.snoutup.baconmaydie-1/libyoyo.so
  native: pc 00000000002ca755  /data/app-lib/com.snoutup.baconmaydie-1/libyoyo.so

backtrace:
  native: pc 00000000002ca748  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca755  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca7d7  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca09f  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002c9a47  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002531b8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Resume+40)
  native: pc 0000000000c09771  /data/app/com.snoutup.baconmaydie-1/oat/arm/base.odex

backtrace:
  native: pc 00000000002ca748  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca755  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca7d7  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002ca09f  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002c9a47  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 00000000002531b8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Resume+40)
  native: pc 000000000055b281  /data/dalvik-cache/arm/data@<EMAIL_ADDRESS>@<EMAIL_ADDRESS>

Following one at least has a bit more information, which could potentially be used to identify the problem.

backtrace:
  native: pc 000000000032c240  /system/lib/libart.so (_ZN3art17InvokeWithVarArgsERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDSt9__va_list+47)
  native: pc 0000000000286b1b  /system/lib/libart.so (_ZN3art3JNI24CallStaticBooleanMethodVEP7_JNIEnvP7_jclassP10_jmethodIDSt9__va_list+338)
  native: pc 000000000015d9d0  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_ZN7_JNIEnv23CallStaticBooleanMethodEP7_jclassP10_jmethodIDz+36)
  native: pc 000000000018dea8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so
  native: pc 000000000018ae00  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z9IO_Updatev+184)
  native: pc 000000000018aef8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z13IO_Start_Stepv+220)
  native: pc 00000000001c8dac  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z7DoAStepv+116)
  native: pc 00000000001ca198  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z16MainLoop_Processv+640)
  native: pc 00000000002552c8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Process+520)
  native: pc 0000000000c0c10f  /data/app/com.snoutup.baconmaydie-1/oat/arm/base.odex

backtrace:
  native: pc 00000000000189fc  /system/lib/libc.so (strcmp+492)
  native: pc 00000000001e0e68  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z21Variable_BuiltIn_FindPKc+64)
  native: pc 00000000001cc470  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z9VARI_LoadPhjS_+324)
  native: pc 00000000001cd1a8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z13GetResolutionPhi+1136)
  native: pc 0000000000260a70  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (_Z10BeginToEndv+152)
  native: pc 00000000002510e8  /data/app/com.snoutup.baconmaydie-1/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+216)
  native: pc 0000000000c31475  /data/app/com.snoutup.baconmaydie-1/oat/arm/base.odex

Is there anything I could do to lower the amount of these errors? Maybe there's a set of devices I could (should?) to exclude from downloading GameMaker games just to be safe?

 

[j_gonfer]

In my experience developing Android Extensions for GameMaker, it's hard to debug Java code due to the YoYo Layer. Errors should tell you the class and method where you are getting the error from the Java code, and by the other side, YoYo layer should tell you in which event your game is crashing. I'm not 100% sure, but the last error you get maybe is related to something about the Resolution Screen of the user's device:

(_Z13GetResolutionPhi+1136)

 

[SnoutUp]

Sad bump, since my crash rate increased recently and I still unsure where to look for the issues.

 

[Tthecreator]

are you using the yyc or not?
If you are not using the yyc you are certainly using the runner and thus it's only natural for it not to work since the runner is like an emulator between your game and the OS, making your game seem very abstract from the OS side.
On the yyc I'm not sure how it works, I tried debugging it on windows once and only found the yoyo layer, but this is probably because they are compressing the game in a weird way. So if you try to find your strings inside a compiled .exe then you're out of luck.

A segmentation error is when some program of piece of codes tries to read or write at some memory location it isn't allowed to access. If you can cause such an error in gml then you've done the impossible. I'm pretty sure there is not a single way to do this in gml, other than trough an extensions or trough abusing build in functions.