• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Android (solved) Libyoyo error. High crash rate on Google Play reports

P

Pushloop

Member
Hi,

I've got an high crash rate in the Android Vitals with my latest game update, but I can't find the problem. It seems related to textures. Anyone can point me in the right direction please? How can I fix this?
These are the top 3 crash messages, they're from android 7 and 8 devices.

Code: 
backtrace:
  #00  pc 0000000000276f30  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z23GR_Texture_Create_BytesiiP18DynamicArrayOfByte+124)
  #01  pc 00000000001ccb00  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_ZN7CFontGM11InitTextureEv+68)
  #02  pc 00000000001d0430  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z17Font_InitTexturesv+60)
  #03  pc 0000000000371f14  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z12InitGraphicsv+220)
  #04  pc 00000000002500c0  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z10BeginToEndv+304)
  #05  pc 00000000002535f8  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+4800)
  #06  pc 00000000000806fc  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/oat/arm64/base.odex

backtrace:
  #00  pc 0000000000276f30  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z23GR_Texture_Create_BytesiiP18DynamicArrayOfByte+124)
  #01  pc 00000000001ccb00  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_ZN7CFontGM11InitTextureEv+68)
  #02  pc 00000000001d0430  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z17Font_InitTexturesv+60)
  #03  pc 0000000000371f14  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z12InitGraphicsv+220)
  #04  pc 00000000002500c0  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (_Z10BeginToEndv+304)
  #05  pc 00000000002535f8  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/lib/arm64/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+4800)
  #06  pc 00000000000806fc  /data/app/xxxxxxxxxxxxxxxx-HwL4xABUoxhdN08gBlBC9g==/oat/arm64/base.odex

backtrace:
  #00  pc 0000000000276f30  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (_Z23GR_Texture_Create_BytesiiP18DynamicArrayOfByte+124)
  #01  pc 00000000001ccb00  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (_ZN7CFontGM11InitTextureEv+68)
  #02  pc 00000000001d0430  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (_Z17Font_InitTexturesv+60)
  #03  pc 0000000000371f14  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (_Z12InitGraphicsv+220)
  #04  pc 00000000002500c0  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (_Z10BeginToEndv+304)
  #05  pc 00000000002535f8  /data/app/xxxxxxxxxxxxxxxx-1/lib/arm64/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+4800)
  #06  pc 00000000004cc0b8  /data/app/xxxxxxxxxxxxxxxx-1/oat/arm64/base.odex
 
Andrey

Andrey

Member
I would like to understand the problem and narrow the search. I don't know at what exact moments these crashes occur (when the app starts or in the process).
Do you have data when exactly this crash occurs?
 
Andrey

Andrey

Member
In the ticket there was a record from Russell (2019-01-24):
“I suspect the device is just running out of memory.. these are all pretty low end devices...”

However, this does not explain the fact that the greater number of failures I see on Samsung devices with memory more than 1500 mb (although perhaps this is due to the prevalence of these devices in the my region - 80% of players).
Maybe on devices in the background a lot of applications are open and the new application has no memory…
 
P

Pushloop

Member
I can't tell when the crashes occur, and the phones aren't necessarily low end. I see Galaxy S6, A5 and Huawei p10 for instance. Strangely i've got a similar game that's based on the same engine but with different graphics that has way less crashes. Also, the crash rate went up after a game update in the store, with no changes to the graphics.
 
Andrey

Andrey

Member
That's interesting! And is there any difference in the dimensions of texture maps (512×512, 1024x1024, 2048×2048) in these games? Do you use any "specific" functions in these games when displaying sprites (texts)? Are you using a texture groups?


I have failures have several options:

Code: 
backtrace №1:
_ZN7CSprite11InitTextureEv

  #00  pc 00000000005a0858  /data/app/com.game.game/lib/arm/libyoyo.so (_ZN7CSprite11InitTextureEv+152)
  #01  pc 00000000005a9e10  /data/app/com.game.game/lib/arm/libyoyo.so (_Z19Sprite_InitTexturesv+72)
  #02  pc 0000000000566e3c  /data/app/com.game.game/lib/arm/libyoyo.so (_Z12InitGraphicsv+204)
  #03  pc 0000000000434cf8  /data/app/com.game.game/lib/arm/libyoyo.so (_Z10BeginToEndv+312)
  #04  pc 0000000000438fa4  /data/app/com.game.game/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+5124)
  #05  pc 0000000000501c95  /data/app/com.game.game/oat/arm/base.odex


backtrace №2:
CSprite::InitTexture()

  #00  pc 00000000005a0858  /data/app/com.game.game/lib/arm/libyoyo.so (CSprite::InitTexture()+152)
  #01  pc 00000000005a9e10  /data/app/com.game.game/lib/arm/libyoyo.so (Sprite_InitTextures()+72)
  #02  pc 0000000000566e3c  /data/app/com.game.game/lib/arm/libyoyo.so (InitGraphics()+204)
  #03  pc 0000000000434cf8  /data/app/com.game.game/lib/arm/libyoyo.so (BeginToEnd()+312)
  #04  pc 0000000000438fa4  /data/app/com.game.game/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+5124)
  #05  pc 0000000000013449  /data/app/com.game.game/oat/arm/base.odex
 
Last edited:
P

Pushloop

Member
Both games have 1024x1024 textures maps, 3 images each. No special functions other then draw_text for text, with draw_set_align, action_font and action_color. For objects I use draw_self. Basically the games are a bit old and imported from 1.4. Didn't check any redundancy in code and afaik i don't use texture groups. Unfortunately my knowledge of code is a bit limited, the games are pretty much drag and drop and very simple, but this crash rate isn't good for the ranking in google :)
 
Nocturne

Nocturne

Friendly Tyrant
Forum Staff
Admin
Can I suggest that you both file bug reports with the Helpdesk about this, and if possible include a download link to the project that gives the issue. Also link to this topic and the previously closed bug report and give as much information as possible abot the devices this happens on, frequency, etc...
 
Andrey

Andrey

Member
Nocturne said:
Can I suggest that you both file bug reports with the Helpdesk about this, and if possible include a download link to the project that gives the issue. Also link to this topic and the previously closed bug report and give as much information as possible abot the devices this happens on, frequency, etc...
Click to expand...
I already filed a report a year ago. Unfortunately, it is impossible to highlight the problem and reproduce it specifically. It is not even clear when it occurs (when you start the application, after a pause or during the game). The problem seems random, but at the same time it is the most common in GooglePlay reports.
Therefore, I would like to narrow the search area to submit a more specific report.
 
Nocturne

Nocturne

Friendly Tyrant
Forum Staff
Admin
Andrey said:
I already filed a report a year ago. Unfortunately, it is impossible to highlight the problem and reproduce it specifically. It is not even clear when it occurs (when you start the application, after a pause or during the game). The problem seems random, but at the same time it is the most common in GooglePlay reports.
Therefore, I would like to narrow the search area to submit a more specific report.
Click to expand...
Yep, I understand that... but a lot can change in a year, and obviously if this is something affecting more than one user then it should be dealt with as a higher priority issue. Even if you don't get more concrete information, please file a report anyway.
 
Andrey

Andrey

Member
Nocturne said:
Yep, I understand that... but a lot can change in a year, and obviously if this is something affecting more than one user then it should be dealt with as a higher priority issue. Even if you don't get more concrete information, please file a report anyway.
Click to expand...
You're right.
I will collect the data that is at the moment, I will send the report again.
 
SnoutUp

SnoutUp

Member
Good luck with this. I've had these crashes for years, in both standard and YYC builds, despite my games running well on potato phones. Never gotten an answer or a hint what could be the problem and if there are workarounds or ways to lower chances of this happening, so I assumed that it's just an inevitability of making mobile games with GM. It's weird that there are so few threads about these issues, so either many devs don't care/check Google Play vitals, lost hope or it does depend on project settings. Helpdesk replies to related reports are not hinting that this is or will be investigated either.
 
Z

ZigZag

Member
This is something I also would love to see further investigated, I have tried to investigate this for quite a while without any real accomplishment, google is taking this quite seriously and crashes are part of their evaluation of app quality behind the scenes, and thus the ranking and success of apps.
So yes, this has to be taken seriously.
 
P

Pushloop

Member
I've been testing some stuff. I thought maybe I didn't have enough API's installed, so I've added some between my min and target SDK, starting from 16, but it only made it worse. Every time I try something and roll-out an update the crash rate goes up. I now think I should clean up all the api's from the SDK manager and only use 1 api. Maybe also go lower in build target. The build set-up I've used is 28.0.3, 28.0.0, 28, 16, 28. My crash rate is now above 2% and it used to be way under 1% with older build set-ups (from gm1.4). Any thoughts?
 
P

Pushloop

Member
Hmm cleaned up the older APK's from the Android Studio SDK Manager, but the crash rate keeps going up. Now I'm skipping the adaptive icons, as a next test.
 
Andrey

Andrey

Member
I have nothing to add, except another report, which is slightly different in its continuation.

Code: 
backtrace:

#00  pc 00000000005a0858  /data/app-lib/com.game.game/libyoyo.so (CSprite::InitTexture()+152)
#01  pc 00000000005a9e10  /data/app-lib/com.game.game/libyoyo.so (Sprite_InitTextures()+72)
#02  pc 0000000000566e3c  /data/app-lib/com.game.game/libyoyo.so (InitGraphics()+204)
#03  pc 0000000000434cf8  /data/app-lib/com.game.game/libyoyo.so (BeginToEnd()+312)
#04  pc 0000000000438fa4  /data/app-lib/com.game.game/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+5124)
#05  pc 000000000001dd8c  /system/lib/libdvm.so (dvmPlatformInvoke+112)
#06  pc 000000000004e253  /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)
#07  pc 00000000000271a0  /system/lib/libdvm.so
#08  pc 000000000002e150  /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
#09  pc 000000000002b7fc  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#10  pc 0000000000060843  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+338)
#11  pc 0000000000060867  /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
#12  pc 0000000000055547  /system/lib/libdvm.so
#13  pc 000000000000d280  /system/lib/libc.so (__thread_entry+72)
#14  pc 000000000000d41c  /system/lib/libc.so (pthread_create+240)

Similar report in another game:

Code: 
backtrace:

#00  pc 000000000004a488  /system/lib/libc.so (tgkill+12)
#01  pc 0000000000047c03  /system/lib/libc.so (pthread_kill+34)
#02  pc 000000000001d6a9  /system/lib/libc.so (raise+10)
#03  pc 00000000000191f5  /system/lib/libc.so (__libc_android_abort+34)
#04  pc 0000000000017264  /system/lib/libc.so (abort+4)
#05  pc 000000000001b6a3  /system/lib/libc.so (__libc_fatal+22)
#06  pc 0000000000065513  /system/lib/libc.so (ifree+962)
#07  pc 00000000000655d7  /system/lib/libc.so (je_free+70)
#08  pc 0000000000331ba4  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN13MemoryManager4FreeEPKv+544)
#09  pc 00000000003a1d74  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN6CLayerD2Ev+32)
#10  pc 000000000038a6a4  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN13CLayerManager15CleanRoomLayersEP5CRoom+184)
#11  pc 000000000037b7bc  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN5CRoom5ClearEv+688)
#12  pc 000000000038251c  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN5CRoomD1Ev+228)
#13  pc 00000000003a25d4  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN12cARRAY_CLASSIP5CRoomE9setLengthEi+204)
#14  pc 00000000003a2200  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN12cARRAY_CLASSIP5CRoomED2Ev+16)
#15  pc 0000000000052237  /system/lib/libc.so (__cxa_finalize+126)
#16  pc 000000000001653b  /system/lib/libc.so (exit+10)
#17  pc 0000000000439d90  /data/app/com.game.game2/lib/arm/libyoyo.so (_Z7YYErrorPKcz+220)
#18  pc 0000000000331e24  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN13MemoryManager7ReAllocEPvjPKcib+296)
#19  pc 000000000033206c  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN13MemoryManager9SetLengthEPPvjPKci+28)
#20  pc 00000000003ea9f4  /data/app/com.game.game2/lib/arm/libyoyo.so (_ZN7CSprite11InitTextureEv+124)
#21  pc 00000000003f4150  /data/app/com.game.game2/lib/arm/libyoyo.so (_Z19Sprite_InitTexturesv+72)
#22  pc 00000000003a6318  /data/app/com.game.game2/lib/arm/libyoyo.so (_Z12InitGraphicsv+204)
#23  pc 00000000002734fc  /data/app/com.game.game2/lib/arm/libyoyo.so (_Z10BeginToEndv+312)
#24  pc 0000000000277544  /data/app/com.game.game2/lib/arm/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Startup+4508)
#25  pc 00000000002af355  /data/app/com.game.game2/oat/arm/base.odex
...On the second report I can assume that failures after an exit from the game (function game_end() ) and a run game again.
 
FrostyCat

FrostyCat

Redemption Seeker
All of these errors seem to occur when trying to allocate texture space for new sprites. Either there's an issue with the runner's allocation routine (which YoYo can do something about), or the games are unlucky to have run on a resource-starved device (which YoYo can't do anything about).
 
N

NetZvezda

Member
FrostyCat said:
All of these errors seem to occur when trying to allocate texture space for new sprites. Either there's an issue with the runner's allocation routine (which YoYo can do something about), or the games are unlucky to have run on a resource-starved device (which YoYo can't do anything about).
Click to expand...
Any walkaround for this? I am going to try using yyc instead of VM and increase the texture page size from 1024 to 2048, I will let you all know how that goes. Also, my previous release used sdk 26, and it didn't seem to have any crashes. Latest released used sdk28 and I got like 20 crashes per 1000, which is really weird.
 
P

Pushloop

Member
With the update of gamemaker, i've uploaded a new version to google play and it seems there are even more crashes now...
 
Andrey

Andrey

Member
I'm seeing a significant reduction in this glitch in my app.
I used YYC, runtime: 2.2.2.325 (beta).

It is possible that my own changes also affect the result.
So:
1. The very first texture group is loaded (sprite_prefetch) after 5 steps the application is launched. The map size of 1024x1024 (all other 2048x2048). The first sprite (and fonts) I draw after 20 steps after the application is launched.
2. I do pre-load the texture groups at intervals of 5 steps before drawing sprites.
3. After a pause, again the application makes pre-load of the texture groups at intervals of 5 steps before drawing sprites.
 
P

Pushloop

Member
Thnx, that's seems like a good thing to try. I've noticed my game being very laggy when starting up. Could be that the textures aren't loaded nicely, so a pre-fetch could take care of it. Can you load all textured at once, before you enter the game? Why do you make intervals of 5 steps? I'm gonna try sprite_prefetch(spr_bla1), sprite_prefetch(spr_bla2), sprite_prefetch(spr_bla3) in the first block of code. I only have 3 texture pages of 1024.
 
Last edited:
Mert

Mert

Member
I get more details and fresh "instant" e-mails whenever I see such crashes. In the reports, I usually see some devices running out of memory. Although I have no idea what causes these crashes, I have some "general insights" what to fix.

Check my Firebase Crashlytics extension here. Open Source and completely free : https://gmdevblog.com/game-maker-firebase-crashlytics/
Enjoy ;)

Edit : Once Yoyo implements try/catch/exception to GML, we'll have more and more detailed crash reports. This will dramatically effect my Firebase Performance Monitoring extension too. For now, waiting for Q4
 
Andrey

Andrey

Member
Pushloop said:
Thnx, that's seems like a good thing to try. I've noticed my game being very laggy when starting up. Could be that the textures aren't loaded nicely, so a pre-fetch could take care of it. Can you load all textured at once, before you enter the game? Why do you make intervals of 5 steps? I'm gonna try sprite_prefetch(spr_bla1), sprite_prefetch(spr_bla2), sprite_prefetch(spr_bla3) in the first block of code. I only have 3 texture pages of 1024.
Click to expand...
I load 1 texture map every 5 steps to avoid a sharp jump in memory consumption. To load grew gradually. Launching the application starts without drawing textures - just a black screen. Loading texture maps for less need: for the splash screen - a texture map for the splash screen, for the menu screen - a texture map menu.
I wanted to understand from the players, at what moments there is a failure - right at the start, after the splash screen, on the menu and so on. But failures have sharply decreased with the introduction of such a system and the release of version rt 2.2.2.325
 
Mert

Mert

Member
Andrey said:
That's interesting! What insights?
Click to expand...
Keys and Logs section include some things I include via firebase_crashlytics_set_string and firebase_crashlytics_set_real just to recreate the scenario.
This error log is instantly e-mailed(notification) to me the minute it happened. In the next hour, I received another similar crash.

If your game is an online game or multiplayer game, you can assign User ID's to crash reports: Giving you a more personalized approach to the crashes (via firebase_crashlytics_set_userid )


 
P

Pushloop

Member
Since the latest update all my games have seen a huge drop in crashes. The libyoyo.so errors are still there, but the crash rates are under 1%, which is pretty good on google play. I can also build from 16 again with Lint activated. From my side I consider this solved.
 
You must log in or register to reply here.
Top