Segmentation Violation with Draw Process

[SolarLune]

Hey, there. I'm using raylib-go, and I'm getting a fatal error from raylib's draw process after a few frames:

package main

import (
	"fmt"
	"github.com/gen2brain/raylib-go/raylib"
)

type Player struct {
	name string
}

func main() {

	raylib.InitWindow(320, 240, "Test Game")

	for !raylib.WindowShouldClose() {

		// Update

		for i := 0; i < 100; i++ {
			fmt.Println(Player{})
		}

		raylib.BeginDrawing()
		raylib.EndDrawing()

	}

	raylib.CloseWindow()

}

And here's the error:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x4e0 pc=0x7f5554e5c8e9]

runtime stack:
runtime.throw(0x53531e, 0x2a)
	/usr/lib64/golang/src/runtime/panic.go:605 +0x95
runtime.sigpanic()
	/usr/lib64/golang/src/runtime/signal_unix.go:351 +0x2b8

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x4bfa90, 0xc420044f08, 0x1)
	/usr/lib64/golang/src/runtime/cgocall.go:132 +0xe4 fp=0xc420044ed8 sp=0xc420044e98 pc=0x41df34
github.com/gen2brain/raylib-go/raylib._Cfunc_BeginDrawing()
	github.com/gen2brain/raylib-go/raylib/_obj/_cgo_gotypes.go:385 +0x41 fp=0xc420044f08 sp=0xc420044ed8 pc=0x4a6e51
github.com/gen2brain/raylib-go/raylib.BeginDrawing()
	/home/solarlune/Documents/Projects/Go/src/github.com/gen2brain/raylib-go/raylib/core.go:518 +0x20 fp=0xc420044f18 sp=0xc420044f08 pc=0x4a7310
main.main()
	/home/solarlune/Documents/Projects/Go/src/solarlune.com/SingleScreen/src/main.go:25 +0xdf fp=0xc420044f80 sp=0xc420044f18 pc=0x4a7bcf
runtime.main()
	/usr/lib64/golang/src/runtime/proc.go:185 +0x20d fp=0xc420044fe0 sp=0xc420044f80 pc=0x44506d
runtime.goexit()
	/usr/lib64/golang/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420044fe8 sp=0xc420044fe0 pc=0x46d8c1

This is a bit of an unusual example that wouldn't come up normally, but I also get a segmentation violation (seemingly randomly) when attempting to load a texture from a filepath. I assume the reason is linked.

[raysan5]

Hi @SolarLune, this issue is difficult to track...

Testing it with raylib C version, it seems to work ok. I'd need a clearer C sample to track the issue...

Maybe is related to Go lang? @gen2brain any idea?

[strangebroadcasts]

This isn't tied to Raylib or the Go binding, but to Go itself. Go implements its own work-stealing scheduler (nicely explained here), which means that Go may move tasks to different OS threads.

Since your loop is allocating a whole lot of Player objects, Go's garbage collection eventually kicks in. (Replacing the loop with a call to runtime.GC() throws the same error immediately.) My guess is that while this is happening, Go moves your main onto another OS thread. Since OpenGL expects all commands to be submitted from a single thread, this leads to weird and unpredictable behavior (i.e. crashing)

The solution is to make one of the threads explicitly responsible for talking to raylib. The easiest way of doing that would be to call runtime.LockOSThread() in the very beginning of main:

func main() {
        runtime.LockOSThread()
	raylib.InitWindow(320, 240, "Test Game")
        // ...

This approach isn't ideal, so for a larger project, I would recommend implementing a way to pass work to the main thread or use a package like mainthread to do it for you.

With that being said, I think it might be good to have a note about calling raylib from the main thread somewhere in the library or binding docs. I don't think the library itself needs to handle multithreading in any way - however, it might not immediately be obvious why you can't, say, create threads to draw sprites in parallel (even moreso in Go, where goroutines are core to the language)

[raysan5]

Just closing this issue here. I'll follow the linked thread...