What does this error mean?

help
1

Hey folks, getting this error when attempting to compile a project on Windows using GitLab's new beta CI runners:

   Compiling gdnative-bindings v0.8.0
memory allocation of 32374784 bytes failed
error: could not compile `gdnative-bindings`.

Caused by:
  process didn't exit successfully: `rustc --crate-name gdnative_bindings --edition=2018 C:\Users\gitlab_runner\.cargo\registry\src\github.com-1ecc6299db9ec823\gdnative-bindings-0.8.0\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=46cbf32cf0256a74 -C extra-filename=-46cbf32cf0256a74 --out-dir C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps --target x86_64-pc-windows-msvc -L dependency=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps -L dependency=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\release\deps --extern bitflags=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps\libbitflags-90ecca2af791642d.rmeta --extern gdnative_core=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps\libgdnative_core-a6d75391be0ce9e4.rmeta --extern gdnative_sys=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps\libgdnative_sys-ce7daf82d70ee84c.rmeta --extern libc=C:\GitLab-Runner\builds\lightsoutgames\godot-tts\target\x86_64-pc-windows-msvc\release\deps\liblibc-10b8e6738dc5aeab.rmeta --cap-lints allow` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
ERROR: Job failed: exit status 1

What does that error mean? I thought maybe I was out of RAM, but it seems like the GitLab Windows runners include 8G, and systeminfo shows only a fraction in use. I have a Windows VM on my desktop with 8G, and successfully ran the compilation there. Further, I'd previously built this on my own VM running gitlab-runner and it worked. I'm leaning toward something breaking on GitLab's end since this is a beta, but if I file an issue, I'd like to have a bit more information on what this error means.

Another difference is that I install LLVM via chocolatey on GitLab's VMs, whereas before I'd installed it manually. Maybe the choco-packaged LLVM versions have issues, even though they're both current? I used to install Rust via Choco too, but switched to using rustup-init.exe manually and the error still persists.

Thanks for any help.

2

Afaik STATUS_STACK_BUFFER_OVERRUN means that there was a buffer overflow, and I'm guessing it's in the build script for the gdnative-bindings crate.

3

That's what I suspected as well. Any idea why it seems to work
everywhere else except for GitLab CI's shared Windows runners? They're
all separate VMs. Wondering if there's some environment variable/setting
I can tweak? I'm a Linux user and know very little about maintaining
Windows systems.

Thanks.

4

Sorry, I'm also a Linux user, and I know very little about maintaining Windows systems.

5

BTW, the GitLab issue I filed is here. Interestingly enough, I confirmed that the runner I replaced this with has half the RAM, so the mystery deepens.

6

Really needing to make this work, I tried on nightly. Now the error is:

memory allocation of 4096 bytes failed

So now I'm even more confused. Is there some sort of environment variable that determines how much memory on the stack/heap is allocated to the compiler under Windows? I'm kind of ignorant of how Windows memory allocation works, so am struggling to determine why these builds fail on a box with twice the resources of one on which they succeed.

7

That failure is probably due to memory corruption and not running out of memory. I suggest filing an issue to the gdnative-bindings crate, as I assume the memory is corrupted by their build script.

8

And that could be true even if the build works fine, as in hasn't failed
this way at all, on other Windows VMs? I know memory corruption can be a
tricky thing, but if a build reliably works everywhere else but reliably
fails on one particular configuration, my inclination is to suspect that
configuration, not the code.

Also, out of curiosity, how can a build script corrupt memory?

Not trying to be argumentative--I just want to understand the issue
better before filing a bug, especially when my inclination is to point
the finger at GitLab's workers, not the crate build system.

Thanks.

9

It may be something else, but it is my best guess. A build script can corrupt memory by using unsafe code. I didn't look through the build script in detail, but it is rather large and calls into other crates.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.