crash with go-findfont package

[SuperGod]

go version go1.19.3 linux/amd64
gcc (GCC) 12.2.0
system: archlinux

When I use the go-findfont package, if I call it too many times, the program will crash.(In the actual code, of course, I only call setupFont once, but sometimes it still crashes when mixed with other codes)
If I set GOGC=off, the program can run normally,.
So I think maybe the c code incorrectly references some memory in go

crash log:

setupFont
setupFont finished
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x840 pc=0x7f32172c4c29]

runtime stack:
runtime.throw({0x8b9e6d?, 0x2031?})
        /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0x7f31ee5e3cb8 sp=0x7f31ee5e3c88 pc=0x50c0fd
runtime.sigpanic()
        /usr/lib/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7f31ee5e3d08 sp=0x7f31ee5e3cb8 pc=0x520289

goroutine 1 [syscall]:
runtime.cgocall(0x58bb10, 0xc000075ea0)
        /usr/lib/go/src/runtime/cgocall.go:158 +0x5c fp=0xc000075e78 sp=0xc000075e40 pc=0x4dca3c
github.com/AllenDang/cimgui-go._Cfunc_igRunLoop(0x17123b0, 0x58b770, 0x58b7e0, 0x58b850, 0x58b930)
        _cgo_gotypes.go:53150 +0x45 fp=0xc000075ea0 sp=0xc000075e78 pc=0x588065
github.com/AllenDang/cimgui-go.GLFWwindow.Run.func1(0x0?)
        /home/super/code/go/pkg/mod/github.com/!allen!dang/cimgui-go@v0.0.0-20221031064022-158164eb30c7/backend.go:76 +0x9b fp=0xc000075f00 sp=0xc000075ea0 pc=0x58849b
github.com/AllenDang/cimgui-go.GLFWwindow.Run(0x8d7778?, 0xc000014018?)
        /home/super/code/go/pkg/mod/github.com/!allen!dang/cimgui-go@v0.0.0-20221031064022-158164eb30c7/backend.go:76 +0x37 fp=0xc000075f18 sp=0xc000075f00 pc=0x5883d7
main.main()
        /home/super/code/gocode/imguitest/main.go:36 +0x18b fp=0xc000075f80 sp=0xc000075f18 pc=0x58b6cb
runtime.main()
        /usr/lib/go/src/runtime/proc.go:250 +0x212 fp=0xc000075fe0 sp=0xc000075f80 pc=0x50e952
runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000075fe8 sp=0xc000075fe0 pc=0x537d61

......

code:

package main

import (
	"fmt"

	"github.com/AllenDang/cimgui-go"
	"github.com/flopp/go-findfont"
)

func afterCreateContext() {
	cimgui.Plot_CreateContext()
}

func beforeDestoryContext() {
	cimgui.Plot_DestroyContext()
}

func loop() {
	cimgui.Begin("Hello")
	cimgui.Text("Hello world")
	cimgui.End()
}

func main() {
	cimgui.SetAfterCreateContextHook(afterCreateContext)
	cimgui.SetBeforeDestroyContextHook(beforeDestoryContext)

	cimgui.SetBgColor(cimgui.NewImVec4(0.45, 0.55, 0.6, 1.0))
	window := cimgui.CreateGlfwWindow("hello", 800, 600, 0)
	fmt.Println("setupFont")
	for i := 0; i != 200; i++ {
		setupFont()
	}

	fmt.Println("setupFont finished")
	window.Run(loop)
}

func setupFont() {
	fontPath, err := findfont.Find("wqy-microhei")
	if err != nil {
		fmt.Println("found font failed")
		return
	}
	_ = fontPath
}

[SuperGod]

I read the code and found that this calling way may cause some problems:

window.Run(go code) -> C.igRunLoop (c code) -> glfwWindowLoopCallback (go code)

"window.Run" call c from go code, and then call go loop from c code,
The stack has been switched twice. I suspect that some memory problems may occur during this switching

[AllenDang]

This is wired...

[eliasdaler]

Hi
Can you please try it out with my fork of ebiten-imgui which uses cimgui-go?
https://github.com/eliasdaler/ebiten-imgui/tree/cimgui-go

See the minimal example of running it here.

Also, I wonder if running your initial program with Valgrind will show memory/stack corruption (not sure how usable it is with Go/CGo programs)

[AllenDang]

@eliasdaler I can reproduce the issue, but I'm currently have no clue how to fix it. When things come to CGO, it becomes tricky...

[eliasdaler]

Yeah, I'm just wondering if it's limited to the GLFW backend or maybe other cimgui-go parts do something wrong.

[SuperGod]

I use gdb to debug it:

(gdb) bt
#0  0x00007ffff77acc29 in ?? () from /usr/lib/libGLdispatch.so.0
#1  0x00000000008901fd in ImGui_ImplOpenGL3_CreateDeviceObjects ()
#2  0x00000000005ac2a1 in glfw_render (window=window@entry=0xc9d3b0, renderLoop=renderLoop@entry=0x58b770 <glfwWindowLoopCallback>)
    at backend.cpp:144
#3  0x00000000005ac3f3 in igRunLoop (window=0xc9d3b0, loop=0x58b770 <glfwWindowLoopCallback>, beforeRender=0x58b7e0 <glfwBeforeRender>, 
    afterRender=0x58b850 <glfwAfterRender>, beforeDestroyContext=0x58b930 <glfwBeforeDestoryContext>) at backend.cpp:216
#4  0x0000000000537a24 in runtime.asmcgocall () at /usr/lib/go/src/runtime/asm_amd64.s:844
#5  0x000000c00009d260 in ?? ()
#6  0x000000c00009d201 in ?? ()
#7  0x00007fffceac9058 in ?? ()
#8  0x00007fffceac3e40 in ?? ()
#9  0x00000000004f0745 in runtime.SetFinalizer.func1 () at /usr/lib/go/src/runtime/mfinal.go:401
#10 0x0000000000535ba9 in runtime.systemstack () at /usr/lib/go/src/runtime/asm_amd64.s:492
#11 0x0000000000000000 in ?? ()

[SuperGod]

I read some glfw code. It just calls c from go, not call go from c.
I think it may be useful only to call c in go

[AllenDang]

@SuperGod but we need callback in several places to make things work

[SuperGod]

@SuperGod but we need callback in several places to make things work
This is a troublesome problem. Maybe we can start by reducing the depth of two-way calls(go->c->go)

[eliasdaler]

Maybe check out how imgui-go did it: https://github.com/inkyblackness/imgui-go-examples
Seemed to work fine for others.

[eliasdaler]

(btw, ideally GLFW backend implementation should be outside of cimgui-go...)

[AllenDang]

@eliasdaler Another repo of mine https://github.com/AllenDang/giu, created a backend manually from glfw in go, which gives me lots of pain, because each time imgui update, I will need to go though the change log and fix all stuff.
That's why this repo uses the backend directly from imgui.

[eliasdaler]

Oh, I see, so it's a backend from Dear ImGui... Yeah, it's cool that it works somewhat, but I won't be surprised if it assumes some things which make CGo break

[SuperGod]

I tried to add a line "runtime.LockOSThread()" to main, it seems that work fine.

func main() {
	runtime.LockOSThread()
	cimgui.SetAfterCreateContextHook(afterCreateContext)
	cimgui.SetBeforeDestroyContextHook(beforeDestoryContext)

	cimgui.SetBgColor(cimgui.NewImVec4(0.45, 0.55, 0.6, 1.0))
	window := cimgui.CreateGlfwWindow("hello", 800, 600, 0)
	fmt.Println("setupFont")
	for i := 0; i != 200; i++ {
		setupFont()
	}

	fmt.Println("setupFont finished")
	window.Run(loop)
}

So I guess it may be that the switch of goroutine causes the cgo stack exception

[AllenDang]

@SuperGod good catch! Make a pr pls!