Android Attempting to allocate HUGE AMOUNT bytes crash

Mool

Member
1634114780632.png


Right now the player can save savesgames and a screenshot of the map is created and stored. Later if he wants to load a savegame all these screenshots gets shown in a menu. (i load them dynamically with sprite_add())

Its super strange, since the .pngs are not that huge. Here an example:

1634115007375.png

Hello does anybody has an idea why this happens?

Is it possible, that sometimes the saved screenshots are over 200MB? I tried to create a 200MB png with paintNET and the resolution was 100k width. So i guess this is not the problem.

surface_save_part(application_surface, screenshotFilename, _x1, _y1, _x2-_x1, _y2-_y1);
 

O.Stogden

Member
Have you got any additional code to share?

178053520 bytes is not a great deal of memory, your phone has 2GB, so should easily be able to allocate that, but it's possible there's an error somewhere in your code which is causing it to use much more.

Have you tried running on Windows with the debugger and looking for memory spikes?
 

Mool

Member
I cant reproduce this bug. It happens very rarely for some of my users. (I submit all unhandled exceptions to my database, therefore i can see, that it happens)

I also get such error messages: Memory allocation failed: Attempting to allocate 896952364 bytes

The number of bytes is random
 

O.Stogden

Member
Hmmm, possibly phone specific then?

The Log you posted is potentially from a 2GB of RAM phone, and the app is getting an error trying to allocate approx. 200MB, it's possible that the user ran out of RAM on the phone and it caused a crash? It's an old phone (Over 4 years old now) running what seems to be a 32-bit version, that could cause issues. A 2GB of RAM phone realistically has close to 1GB to use for apps, if he's running more than 1 app at once, it could cause instability.

Hard to diagnose without getting the error yourself, you don't know what devices these guys are using, what other apps they may have running in the background using up RAM, etc.

It might be an idea to remove the 32-bit version of the app (if indeed there is one) and just support ARM64, as no-one uses, or really has a 32-bit only phone anymore. GMS and Google have both pretty much pulled support for it.
 

Mool

Member
Yeah I often heard that suggestion to unsupport all devices below 1GB or RAM, but then I will lose a lot of players.

I added a try catch around sprite_add(). It isnt a good solution, but as you said its super hard to debug without crashlytics + deobfuscation symbols. (hope we will get them soon, since YYG releases a 1. party crashlytics extension)

Sadly try catch doesnt work for silent crashes. Thanks
 

O.Stogden

Member
Yeah, I guess it depends on the nature of your app as to whether you want to support old devices.

If it's a game, I'd remove support for 32-bit and any device with less than 2GB of RAM. These represent less than 5% of Androids userbase now. Plus it's harder for those users to find your game, as they have no access to the Google Play Store etc. Google only lets Android 5+ devices and 64-bit devices use the Play Store, and both of those should be running 2GB of RAM, unless they're a very cheap unbranded device, which people shouldn't really expect to be able to run games anyway.
 

GMWolf

aka fel666
Is it possible, that sometimes the saved screenshots are over 200MB? I tried to create a 200MB png with paintNET and the resolution was 100k width. So i guess this is not the problem.
A 7k by 7k texture would use up about 200MBs of memory. If you are taking 1080p screenshots, you would only need 24 screenshots to reach 200MB.

I would recommend saving thumbnails rather than large screenshots.
 

Mool

Member
@GMWolf

Why 200MB? 7000x7000 x4Byte (rgba) ???

Isnt .png compressed? nvm

1634153372035.png

Yeah I store only #macro SCREENSHOT_SIZE 300 (-->WIDTH) thumbnails

I dont get why its sometimes so big.
 

Mool

Member
Yeah, I guess it depends on the nature of your app as to whether you want to support old devices.

If it's a game, I'd remove support for 32-bit and any device with less than 2GB of RAM. These represent less than 5% of Androids userbase now. Plus it's harder for those users to find your game, as they have no access to the Google Play Store etc. Google only lets Android 5+ devices and 64-bit devices use the Play Store, and both of those should be running 2GB of RAM, unless they're a very cheap unbranded device, which people shouldn't really expect to be able to run games anyway.

Yeah maybe next year, since idk the impact on ASO if i do it.
 

O.Stogden

Member
Well an image file size such as .png isn't necessarily affected by the size of the actual image, it's more affected by the data in the image.

A blank white PNG will use far less space than a detailed screenshot, even if they're both 1920x1080 for example.
 

GMWolf

aka fel666
Why 200MB? 7000x7000 x4Byte (rgba) ???

Isnt .png compressed? nvm
Im talking about the size in vram (or on a phone, just ram, its unified (ignoring tile memory for a second).
GMS doesnnt use gpu compression so it will be 4bpp.
 

Mool

Member
Ahhhhh I see thats super clever. Thanks.

I also see, that its always pow2 texture sizes. I will try a 7k image

The images on SSD are all 90KB, but in VRAM 512x256x4byte like you said. (since size is 300px -> i should try 250px as size)

1634155594929.png
 

Mool

Member
I realized something. If I sprite_add an image, then shortly (1s) the memory allocation is x3, before it wents back to normal again.

I guess gms is doing something internal, which shortly uses a lot of RAM during sprite_add(), before its getting freeed again and i am able to use this sprite
 

TheouAegis

Member
How many Sprites are you loading all at once? Do you really need to load everything all at once? If not already, can you not just load one Sprite and free it when looking at the next so you only have one sprite loaded at a time?
 
Top