GMS 2.3+ Array dimension gets garbage-collected in middle of loop in VM? (not in YYC).


I have structs, which hold 3D and 4D arrays. Structs have Update and Draw -methods, which loop through these arrays. There are no problems when using YYC, and it runs smoothly.

Problem resides when I use VM and Debugger.
- Running Draw-method shows all items in arrays exist, so initialization is not a problem. Also verified this with debugger.
- Whenever I run Update-method, last dimension might become empty. Update-call is heavier than Draw.
- Problem occurs randomly during or after Update-call. It can happen in same frame, but also after several frames have passed after executing Update.
- This doesn't happen every time, certain situations make it more likely.
- Error states following. Actual Index can vary, as sometimes this occurs in middle of loop, and index can be something like "5".
Variable Index [0] out of range [0]
It seems that entries on last dimension got garbage-collected -> eg. array[w][h][c] values have became undefined, dimensional structure exist.
- Usually all items on last dimension become undefined, but sometimes only partly.
I have been trying to pinpoint this problem for several hours, and my testing points towards gc instead having problem in the code. (Of course there is that possiblity).
- When I disable gc, there is no problem with arrays.
- By reading gc_stats I understand gc happens before problem.
- Having gc as cause would explain seemingly random timing of problem after Update-call.
- Just to mention, I have cleared cache several times.
Update method is heavier and usually isn't called every frame. Draw-method is called constantly for drawing arrays.
- Problem is more likely to occur when arrays are larger + more complex. Larger arrays make calling Update more heavy.
- Problem is likely to happen when Update-call takes long enough. Though this isn't surefire.
-> I have tried to make arrays large enough to make GMS struggling to run without problem occurring. But then rerunning project can make problem happen.
-> Making Update call every frame, then stop and start Updating again can cause it?

Here are some errors I have managed to get:
Two bottom erro rmessages only have happened once.
- First I don't know how Unknown Software Expection error happened. can have occurred during I tried enabling/disabling gc.
- Second, having error happen at Tanh-function is bit mystery, because error should have happen when accessing the value (color = output[w][h][c], then color = NeuronColor(color)). Could input-argument have been collected xD

So I think it is gc-related, but what do you think? Could there be something else to look for? I have no clue, so enlight me :)



Still struggling with this, bit annoying that I cannot use VM for testing, wouldn't mind though if YYC compile time was faster.
When I kept testing with gc off, I managed to find 'memory leak' (which gc was keeping under control), which is fixed now and memory usage stays in healthy levels even without gc on.
But that did not fix the original problem.


ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
If it is reliably reproduceable (as in, you run the game and it will bork less than a minute later), I would highly suggest to file a bug report with your project attached - I've seen my share of oddities with garbage collection in my GMLive extension, but my data is highly nested and it's hard to make anything crash reliably.


YAL's suggestion is good:

First can you reliably reproduce it.
Second can you reliably reproduce it in a small test project.
Third submit a bug report with small project that reproduces the problem.

The process of creating a small test project that reproduces the issue will inform you if it is a bug with GC or your own code.

Good luck.


Yeah I will do that. I managed making it happen everytime, copied code to empty project and started snipping parts away, until I had only 'essentials' left to have similiar data-structure.
So it does indeed only happen only in VM with gc enabled, with disabled gc or YYC it won't happen.
When running VM gc disabled, memory usage doesn't have odd behaviour and code runs as expected.