Just now I realized there is a new release available. So I reran the builds. The problem persists, and I updated my list above…
Added v5.1.155.
Hmmm, I see the same error as described in "Error: memory access out of bounds" when using online build server.
Could it mean it is the same root cause? After all my pipeline behaves like a build server, too.
It doesn’t look like the same error, but feel free to try the fix. If you don’t know what environment variables are, look here for an example: Adding Node.JS to the system path - HackMD
(not saying that this is a tutorial that will work in your situation, but it will show you how/where to proceed)
While I know about environment variables in general, it would help tremendously to know which variables should be set to which value.
If it is all about putting node.js into the system path - that is unlikely the issue I am facing.
I looked at your post but we don’t have the same error.
My problem was because my game is very heavy so I compiled it manually.
I used Node.js version 18.12.1
The latest version of Android Studio.
Gradle 7.6 binaries
I got stuck on the “cordova build android” command but fixed it by setting the environment variables. I did the same as in the video and it worked for me, but it is in Spanish because I searched in my language
Thank you for the response. Again you do not mention what variables to set. And my spanish is not good enough to follow that tutorial.
But as it covers a Gradle installation I guess that setting variables for Gradle will not help in my case.
So this issue seems an ever-reoccurring item. I was able to reproduce it on every release since 5.1.150 (see table above). It is not resolved. But…
-
"Error: memory access out of bounds" when using online build server
The issue was resolved by setting gradle environment variables. -
memory access out of bound
The issue was resolved by reducing the amount of global objects -
RuntimeError: memory access out of bounds (Solved)
The issue was resolved by reducing huge image files
Now for me the issue came up on projects that compiled successfully on GDevelop versions before. Plus it also happens on the example project Absorbus - a game example from the GDevelop game making app | GDevelop. It still looks to me that for some reason recent versions of GDevelop need considerably more memory than before, and the fixes mentioned all smell like workarounds.
Is there some way to specify the allowed memory when running gdexporter?
This is not a problem of running out of memory - this is a problem of memory corruption. WASM notices that access to unallocated memory was attempted, which happens in C++ when accessing an index higher than the capacity of an array, reaching for memory beyond the allocated array. Of course, this issue could come from anywhere, and why it happens only in GDexporter is a mystery to me… I am guessing some parameter for some GDCore function have changed, and by passing in outdated parameters an API contract is broken or something. The solution would likely be to rework GDexporter to, instead of using pre-made glue code, extracting that glue code from the gdevelop source code.
That might take some effort on GdExporter. Is a fix likely to come? Or how soon could be a realistic date?
Should I simply stick to the last working version 5.1.149?
honestly, i don’t really have the time to work on fixing this´currently, so i’d recommend staying on an old version as a workaround for now yes
1 Like
Hey @hiran, try to use gdexporter@3.2.12 with the latest version of GDevelop.
I’ve made some changes that might solve your problem as well.
1 Like
Confirmed!
A long time ago my pipeline went into failure mode, but now it returned back to success.
Thanks a lot for fixing - whatever had to be fixed.
