Segmentation fault / panic on startup (Arch Linux)

[Jsewill]

Invoking gd run in any of the examples' directories, simply results in a segmentation fault. No other output. I'm testing on Arch linux, with Godot 4.2.1 already installed.

[Splizard]

Thanks for the report, I'm guessing you are on an amd64 system. Do you know which C compiler is being used for CGO?

[Jsewill]

I did run it on an amd64 system. Is this not meant for that? I assume it is gcc, which is version 13.2.1 on this system. Is there a particular way to determine which compiler is actually used by cgo?

[Splizard]

No that's the supported platform, I'll need to see if I can reproduce.

[Splizard]

I haven't been able to reproduce on Ubuntu (amd64) with GCC 11.4.0 and Go 1.21

@Jsewill just to confirm, you are running gd run on directories in the example repo? https://github.com/grow-graphics/eg

I've updated the go.mod in this repo to point at the latest commit here, (just in case this has been resolved with the latest version of the project), please do try to run gd run again after pulling the latest changes in the examples repo.

Is there a particular way to determine which compiler is actually used by cgo?

go env CC (it's probably gcc).

[Jsewill]

Here's what I get when I run the 1d/helloworld example from the eg repository, after running installing the latest gd:

[redacted@redacted helloworld]$ gd run
go: downloading grow.graphics/gd v0.0.0-20240302115347-3481897a68b7
go: downloading runtime.link v0.0.0-20240302024459-872f5bf0d72b
go: downloading grow.graphics/xy v0.0.0-20240129001410-305eed4d9a6a
go: downloading grow.graphics/uc v0.0.0-20240128001120-57fde712a2f4
signal: segmentation fault

go env CC returns gcc, and gcc -v returns gcc version 13.2.1 20230801 (GCC)

[Jsewill]

I've been looking for a way to work with Godot in Go, and was really excited to give this a try. I very much hope this takes off.

I just tried following the instructions at https://github.com/grow-graphics/gd?tab=readme-ov-file#examples, and got this:

[redacted@redacted example]$ godot project.godot 
Godot Engine v4.2.1.stable.arch_linux - https://godotengine.org
Vulkan API 1.3.277 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3060

Godot Version is:  Godot Engine v4.2.1.stable.arch_linux
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7555d75c0aa1]

goroutine 17 [running, locked to thread]:
grow.graphics/gd/internal.String.Length({{}, {0x7555d757d25d?, 0xc00017cf90?}})
    /redacted/gd/internal/all.go:1437 +0xc1
grow.graphics/gd/gdextension.linkCGO.func58({{}, {0xc00017cf90?, 0xc00017cf90?}})
    /redacted/gd/gdextension/gdextension_interface.go:1362 +0x2f
grow.graphics/gd/internal.String.String({{}, {0x0?, 0xc00017cf90?}})
    /redacted/gd/internal/strings.go:47 +0x7c
grow.graphics/gd/internal.Context.GetLibraryPath({{0x7555d7a990f8?, 0xc00017ce70?}, 0xc000186000?})
    /redacted/gd/internal/ctx.go:58 +0x30
main.main()
    /redacted/gd/example/src/main.go:112 +0xe5
grow.graphics/gd/gdextension.loadExtension.func2(0x0?, 0x2)
    /redacted/gd/gdextension/cgo.go:82 +0x2f
reflect.Value.call({0x7555d78b1ac0?, 0x7555d7a96ee0?, 0xc0001e9d30?}, {0x7555d772f313, 0x4}, {0xc00017cea0, 0x2, 0x0?})
    /usr/lib/go/src/reflect/value.go:596 +0xce5
reflect.Value.Call({0x7555d78b1ac0?, 0x7555d7a96ee0?, 0x0?}, {0xc00017cea0?, 0xc000006700?, 0xc0001e9e20?})
    /usr/lib/go/src/reflect/value.go:380 +0xb9
Aborted

Needless to say, Godot tried to launch, even looked like it had opened the project, but crashed immediately.

[Splizard]

Thanks for the additional details, I am able to reproduce with the following Dockerfile, the second-to last command panics with the same trace. This will help me to investigate the issue.

FROM archlinux:base-devel

RUN pacman -Sy
RUN pacman -S --noconfirm go godot git 
WORKDIR /home
RUN mkdir git
WORKDIR /home/git
RUN git clone https://github.com/grow-graphics/gd
WORKDIR /home/git/gd/example
RUN make
RUN timeout 5s godot --editor --headless
RUN timeout 5s godot --headless

[Splizard]

Looks to be resolved, have confirmed using Docker, had something to do with GDExtensionInitializationLevelCore not being triggered on startup (some sort of quirk with the Arch build of Godot?). Note, for compatibility with gd run you will want to make sure that your godot binary can be found inside your system path as godot-4.2.1, then the gd commands will work as expected (make sure to reinstall the latest version).

Do raise an issue if/when you run into any more problems!

[Jsewill]

This seems to have fixed the example on the main repository, but the ones at https://github.com/grow-graphics/eg still segfault without any indication as to why. I did install gd again, and I pulled the aforementioned repository just before testing it again.

On a different topic: Do you have a project roadmap, or any plans for continuing improvements on this project? I greatly enjoy working with go, and I would like to build a game using it and godot. It seems like a great combination, especially if it can be brought up to parity (within reason). Part of the draw of godot is its cross-platform compatibility. In my very limited experience, other go projects like this tend to be abandoned, or underdeveloped. It would be awesome if this project turns out to be something on which a proper game project could be built. All the polymorphism in gdscript gives me a headache, I don't care much for C#, and haven't touched C++ in years.

[Splizard]

I suspect the gd command is using the version available from the Godot website and not the version you likely have installed via pacman. Can you try opening up the project manually?

As for the roadmap question, it may be worth opening a Github discussion on this topic? I'll get back to you with an more substantial answer.

[Jsewill]

I'm running Godot 4.2.1, which is what is available on the website. Here's the output I get when I open the 1d/helloworld example, manually:

graphics]$ godot project.godot 
Godot Engine v4.2.1.stable.arch_linux - https://godotengine.org
Vulkan API 1.3.277 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3060

Hello, World!
PASS

the Godot window opens very briefly, but closes immediately. The 2d/pong example opens just fine, manually, and even runs when launched from within godot. Both segfault when attempting gd run.

[Splizard]

Thanks, I think you've confirmed the issue here, notice that when you run godot manually, the project is being launched with v4.2.1.stable.arch_linux. When you are running gd run, the command has downloaded the generic linux version and has added it inside your $GOPATH/bin.

The generic version may have a compatibillity issue with Arch Linux. I will look into adjusting the gd tool to take this into account and ensure the system installed version of Godot is preferred. In the meantime you can symlink your godot binary as godot-4.2.1 so that it csn be found in your $PATH.

[Jsewill]

Thanks, I'll symlink it for now. Is there a reason it doesn't check for a system installed version of godot?

UPDATE: creating a symlink worked.

[Splizard]

Hi @Jsewill,

I wanted to address some of your other questions

Do you have a project roadmap, or any plans for continuing improvements on this project? I greatly enjoy working with go, and I would like to build a game using it and godot. It seems like a great combination, especially if it can be brought up to parity (within reason). Part of the draw of godot is its cross-platform compatibility. In my very limited experience, other go projects like this tend to be abandoned, or underdeveloped. It would be awesome if this project turns out to be something on which a proper game project could be built. All the polymorphism in gdscript gives me a headache, I don't care much for C#, and haven't touched C++ in years.

My personal motiviation for this project is to create a multi-user creative space using Go + Godot, the sort of space where people can interact with a 3D scene in real-time. I've been following a recently open-sourced project with similar aims, The Mirror. I'm supportive of this project and have been assessing it, it's good for third-person and first-person perspectives and for physics-based spaces. It's not technically suited at creating large-scale simulation-based spaces, think of a city building space, a theme park editor or a zoo designer.

So as far as Go + Godot continues to be useful in this aim, I will be looking to maintain this project. As far as a roadmap goes, the scope for this is to address the Known Limitations listed in the readme and continue to update the project to support the latest stable Godot version.

As for improvements, the memory safety and usability aspects of the project are reliant on exploration, the project needs things to be built with it. I'm certainly looking for feedback, difficulties, etc. At the moment, I think the project requires a good understanding of both Go and Godot to be used effectively. It would be nice if it were more approachable to those who are only familiar with one or the other.

As for the project lifetime, there is no investment, or company backing this. It has 20% the number of stars of the next biggest Go + Godot implementation. I've made an effort to raise awareness of the project so that it will be discoverable by those who are interested in it. I've conciously avoided polymorphism and have an aim to ensure the foundations of this project will not become a performance footgun (memory allocation wise) for those who want to leverage it for their work.