GDevelop Exporter / memory access out of bounds / all versions since 5.1.150

GDevelop general
1

Similar symptoms as in GDExporter cannot find GDevelop Core - #7 by hiran

My pipeline is running GDevelop Exporter to recompile games that have compiled successfully before - but now the pipeline fails. Here is the error:

TypeError: Failed to parse URL from /usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.wasm
    at Object.fetch (node:internal/deps/undici/undici:11118:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Emitted 'error' event on WrappedGD instance at:
    at Object.onAbort (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/WrappedGD.js:51:28)
    at process.abort (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:15232)
    at process.emit (node:events:513:28)
    at emit (node:internal/process/promises:149:20)
    at processPromiseRejections (node:internal/process/promises:283:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32) {
  [cause]: TypeError [ERR_INVALID_URL]: Invalid URL
      at new NodeError (node:internal/errors:393:5)
      at URL.onParseError (node:internal/url:565:9)
      at new URL (node:internal/url:645:5)
      at new Request (node:internal/deps/undici/undici:9472:25)
      at Agent.fetch2 (node:internal/deps/undici/undici:10291:25)
      at Object.fetch (node:internal/deps/undici/undici:11116:28)
      at fetch (node:internal/process/pre_execution:216:25)
      at instantiateAsync (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:17055)
      at createWasm (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:17655)
      at /usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:95499
      at getGD (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/downloadGD.js:208:57)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
    input: '/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.wasm',
    code: 'ERR_INVALID_URL'
  }
}

Node.js v18.12.1
+ exit 1

Would I have to upgrade my Node.js installation? Is there some resource not available that should be?

2

Try the same fix as in your topic that you linked yourself :sweat_smile:
Node.js v16.

3

As Greench mentioned above, you would have to downgrade your node installation. Only v16 is supported per the dev in that thread.

4

Bummer. I could/should have spotted that. So last time I switched to node:lts, but the version behind must have changed. So now I used node:16. However the problem looks different now:

NODE_VERSION=16.19.0
...
RuntimeError: abort(RuntimeError: memory access out of bounds). Build with -s ASSERTIONS=1 for more info.
    at process.abort (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:15364)
    at process.emit (node:events:513:28)
    at emit (node:internal/process/promises:140:20)
    at processPromiseRejections (node:internal/process/promises:274:27)
    at processTicksAndRejections (node:internal/process/task_queues:97:32)
+ exit 1

As it seems my last known-good version is NODE_VERSION=16.16.0

5

Sad but true. I changed back to NODE_VERSION=16.16.0.

Now the build still fails, and here is my output:

NODE_VERSION=16.16.0
…
RuntimeError: abort(RuntimeError: memory access out of bounds). Build with -s ASSERTIONS=1 for more info.
at process.abort (/usr/local/lib/node_modules/gdexporter/node_modules/gdcore-tools/src/Versions/v5.1.153/libGD.js:9:15364)
at process.emit (node:events:527:28)
at emit (node:internal/process/promises:140:20)
at processPromiseRejections (node:internal/process/promises:274:27)
at processTicksAndRejections (node:internal/process/task_queues:97:32)

  • exit 1

So now that the node version is the same as that time, I will have to look at gdexporter itself.
Running v5.1.153.
Last known-good is v5.0.140

6

NODE_VERSION=18.12.1, GDevelop Runtime ‘v5.1.151’ → TypeError [ERR_INVALID_URL]: Invalid URL
NODE_VERSION=16.19.0, GDevelop Runtime ‘v5.1.153’ → RuntimeError: memory access out of bounds
NODE_VERSION=16.18.1, GDevelop Runtime ‘v5.1.153’ → RuntimeError: memory access out of bounds
NODE_VERSION=16.17.1, GDevelop Runtime ‘v5.1.153’ → RuntimeError: memory access out of bounds
NODE_VERSION=16.16.0, GDevelop Runtime ‘v5.1.153’ → RuntimeError: memory access out of bounds

Does not look like a Node issue this time. I have the feeling the issue is somewhere between GDevelop Runtime v5.0.140 and v5.1.153.

7

Hmmm… I had gotten this error too recently and didn’t think much of it as I had seen the same error randomly pop up for other people and thought it must have been something with my project, but if it happens to you too… I’ll have to look into that, although my time is limited currently so it might take a while

1 Like
8

Do you get the same error if you try the same with one of the example projects?
How big is your project folder in megabytes?

1 Like
9

My git repository, cloned and containing all my GDevelop projects (that get compiled one by one) spans 210 MB, including the .git folder.
The biggest single project out of that folder is 98 MB, one is 15 MB and the remainder less than 5 MB each.

Aha, I just verified the process breaks on the first project, which is the 98MB thingy. And in here, the majority is just sound data:

$ du -sh *
160K	game.json
160K	game.json.autosave
1,1M	images
97M	sounds
$

The project has not changed since two years and got recompiled successfully on a regular base. So I would not believe if the machine all of a sudden would not have enough memory any more.

10

In the meantime, is there some way for me to run on some older exporter? How to accomplish that?
I guess it would be sufficient to specify the version on the line installing gdexporter (‘npm i -g gdexporter’), although I am not knowledgeable on node packages still.

My Dockerfile looks like this:

FROM node:16
RUN mkdir /project
RUN mkdir /output
RUN npm i -g gdexporter
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
#CMD [ "-p", "/project", "-o", "/output" ]
VOLUME ["/usr/local/lib/node_modules/gdexporter/node_modules"]
11

Whew, that is interesting.

I used Absorbus - a game example from the GDevelop game making app | GDevelop as example project - just verbatim.
That means I created it within the IDE and stored it into another folder within my git repository. It would then be compiled first, before even my other projects. And I see the problem again!

NODE_VERSION=16.19.0, GDevelop Runtime ‘v5.1.153’, Project Absorbus → RuntimeError: memory access out of bounds

12

If the dev (Arthuro) for that external project (gdexporter) can’t give you a solution, you may be out of luck using that external utility.

He mentioned he’s looking into it, but in the interim I would try the normal compilation process for manually publishing using yarn and electron builder as listed on the wiki.

If that doesn’t work with the absorbus ptoject it might be something specific to your machine. If it does work it is something specific to gdexporter.

13

(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)

14

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

15

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.

16

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.

17

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.

18

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.

19

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
21

Thanks, this will be helpful for debugging :+1: