In-Game: [Android] string_replace_all() causing SEGV_ACCERR on Galaxy S24 device

[gm-bug-reporter]

Description

After a long time of the user playing multiple sessions, the game silently crashes when attempting to manipulate a string using "string_replace_all" on a string from "ds_list_write" during the saving process.

This only seems to happen on a specific string_replace_all (when the game is saving its "logbook" file) even though the event (User Event 0 in obj_save) uses multiple instances of this function. The process of saving that file involves two string_replace_all calls, one inside a do loop and one before the loop. The crash seems to occur in both of those apparently-randomly.

The attached text file has a more detailed crash log, specifically citing "Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xb40000777f5c8000 in tid 7256 (GLThread 48), pid 7224 (ioid.settlemoon)". Galaxy S24 (Android 14-11).

Steps To Reproduce

This one's going to be hard to reproduce, as this has only shown up after many sessions, and their save file is nigh-inaccessible due to how Android phones lock down files. But to them all they needed to do was hit Enter World and go through the loading screen until it finishes updating and saves.

Which version of GameMaker are you reporting this issue for?

IDE v2024.8.1.171 Runtime v2024.8.1.218

Which operating system(s) are you seeing the problem on?

Windows 10.0.22631.0

Which platform(s) are you seeing the problem on?

Android

Attached Files

• message(1).txt
• 0.jpg

b6414a0a-e447-42a0-a55a-629e8cf354f7

[jackerley]

Hi, can you give me instructions on how to get to the point where saving is taking place in the game?

[The-Giik]

Hello, I'm the one that originally reported this problem. I seem to have fixed it in a way.

So, the saving part that was crashing was the logbook, which is a ds_list of arrays, and each array had about 4 entries. 3 of those entries were reals, but one was a string about 12 characters long.

Usually the game trims that list down to about 700 entries if it detects the file size getting too big, but only on saving. The users experiencing the crash seemed to get to over 2000 entries in the list before it attempted to save. Naturally using ds_list_write() on a 2000-entry-long list of arrays results in an absurdly large string. It seemed to handle WRITING the string okay, but attempting to ACCESS that string via string_replace_all caused the crash. It probably didn't help that trimming down the list was just a do loop that removed an entry and re-wrote the string until it fit the file size. Works fine if you only need to trim 2-3 entries off, less so if you need to trim 1300 entries.

Anyway, I fixed it by trimming it down to 500 entries if it detects over 1000 entries before it even gets to the ds_list_write(). In hindsight I probably should have done that first, but I already had a list-trimming algorithm in place so I hadn't thought about that.

I figure this doesn't happen on PCs because their RAM is usually way higher than android phones.

So, to replicate it, generate a ds_list with a few thousands arrays in it, use ds_list_write() on that list, and try using string_replace_all() on the resulting string.

No idea how you'd even try fixing manipulating ridiculously long strings, but hey I don't work for YYG. Good luck fixing it though! Maybe just giving the user an error window instead of a silent crash would suffice.

[jackerley]

Hi, I tried putting a sample together that does as you describe, but it handles 16k arrays being added to a ds_list and running string_replace_all on the result string without any problems. If you can isolate this to a reproducible sample I'd be very interested to take a look?

Thanks,
Fritz

[YYDan]

If you do recreate the problem and can make the requested sample project, etc., then please file a new issue (don't comment here!) and ensure you allow the bug-reporter inside GM to send that project as part of the initial bug submission.

Thanks.