(Note that GDexport is not an alternative to electron builder - it’s an alternative to using GDevelop’s GUI for doing a manual export for manually publishing using yarn and electron builder)
Sure, but using the normal export process will help check if something weird is going on with their machine, and if they cant do that it indicates one thing, but can do that and can’t build thats another thing, etc
The machine I compile on is a server without a GUI, and I run GDexporter in a docker container.
I do not see a reasonable way to run the GUI on that server or from within a docker container.
Of course I can compile on my desktop machine using the GUI. But as it is not the same machine it would tell us nothing about a quirky setup.
Yet on the other hand, I posted my Dockerfile and it should not be too difficult for someone to try such a build. I can assist if need be.
I have seen people get some odd build errors when using the online build service over the past few months, but only at random. The hope was to identify if it is related to your project (by testing with a normal project, which you’ve now done), with GDevelop (by using the normal export process), or if it is GDExporter exclusively.
If it is GDexporter, you really should be continuing this discussion on the github for GDexporter.
I just learned about the command
npm repo gdexporter
which guides me to GitHub - arthuro555/gdexporter: A CLI to export a GDevelop Game without the IDE with plugins support.
At least now I can also see the Gdexporter version numbers - I am on 3.2.8 (current).
And I am wondering whether it is possible to install an earlier version.
I doubt the GDexport version would change anything - I did not upload an update recently, and I test it before releasing it. I think it’s more likely related to the gdevelop runtime version, which you can change with a cli flag.
Looking at that documentation I realize that I am (still) calling gdexporter like
/usr/local/lib/node_modules/gdexporter/bin/cli -p ${PROJECT_FILE} -o ${DEST}
Should I switch to gdexporter? What directory would that be in?
EDIT: I just found this symlink:
/usr/local/bin/gdexport -> ../lib/node_modules/gdexporter/bin/cli
so actually it does not matter.
Nevertheless now I am getting some success. I ran my last known-good configuration like
/usr/local/lib/node_modules/gdexporter/bin/cli -p ${PROJECT_FILE} -o ${DEST} --tag v5.0.140
and all my projects (including Absorbus) compiled successfully. I will now try different GDevelop versions to refine which version still works and where it starts failing:
node 16.19.0, gdexporter 3.2.8, gdevelop v5.0.140 → successful
node 16.19.0, gdexporter 3.2.8, gdevelop v5.0.146 → successful
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.147 → successful
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.148 → successful
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.149 → successful
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.150 → RuntimeError: memory access out of bounds
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.151 → RuntimeError: memory access out of bounds
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.152 → RuntimeError: memory access out of bounds
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.153 → RuntimeError: memory access out of bounds
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.154 → RuntimeError: memory access out of bounds
node 16.19.0, gdexporter 3.2.8, gdevelop v5.1.155 → RuntimeError: memory access out of bounds
I think that is as much as I can test. Someone will have to follow up on whether this is a GDevelop or an exporter issue, and what exactly has introduced this starting with v5.1.150.
1 Like
Thanks, this will be helpful for debugging 
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.
