2.24.0 MacOS+x64 TTF_RenderUTF8_Blended_Wrapped segment fault

[shellohunter]

I'm using sdl_ttf in a go binding lib, here's the binding src:
TTF_RenderUTF8_Solid:
https://github.com/veandco/go-sdl2/blob/4dff63cf3caad3d340b13c6663cd4219a034463f/ttf/sdl_ttf.go#L289
TTF_RenderUTF8_Blended_Wrapped:
https://github.com/veandco/go-sdl2/blob/4dff63cf3caad3d340b13c6663cd4219a034463f/ttf/sdl_ttf.go#L327

when using TTF_RenderUTF8_Blended_Wrapped , my program has a very high chance that crashes with a segment fault signal.
but no crashes once I replaced it with TTF_RenderUTF8_Solid.

I've debugged the golang part, seems everything is fine as expected. So it could be the SDL issue.

and some other info:

• same code tested on various platforms, crash not seen on MacOS arm64, Win64, linux x64, only on MacOS intel64. I'm not 100% sure about the conclusion though, maybe it's a matter of timing?
• it does not crash in simple test cases, like just drawing a text on screen. the more complicated, the more chance to crash.
• as go-sdl2's doc, the binding has thread-safe kept in mind, all sdl calls are piped into the main thread to execute sequentially.

any advice?

[slouken]

What's the stack trace inside SDL_ttf?

[shellohunter]

@slouken after some study, I still don't know how to recover the c stack of a cgo crash.
here's the stack trace from go. I'll post a new one if I find a simpler test case :

SIGSEGV: segmentation violation
PC=0x108fb4620 m=0 sigcode=1 addr=0xb01dfacedebac1e
signal arrived during cgo execution

goroutine 1 gp=0xc0000061c0 m=0 mp=0x1088729a0 [syscall, locked to thread]:
runtime.cgocall(0x1085a2b70, 0xc000133d08)
	/usr/local/go/src/runtime/cgocall.go:167 +0x4b fp=0xc000133ce0 sp=0xc000133ca8 pc=0x1083c43ab
github.com/veandco/go-sdl2/ttf._Cfunc_TTF_RenderUTF8_Blended_Wrapped(0x7f9d60854a00, 0x7f9d5fa48510, {0xff, 0xff, 0xff, 0xff}, 0x0)
	_cgo_gotypes.go:802 +0x4c fp=0xc000133d08 sp=0xc000133ce0 pc=0x10857376c
github.com/veandco/go-sdl2/ttf.(*Font).RenderUTF8BlendedWrapped.func2(0x1085a879e?, 0x7f9d5fa48510, {0x90?, 0x3d?, 0x13?, 0x0?}, 0x0)
	/Users/shello/go/pkg/mod/github.com/veandco/go-sdl2@v0.5.0-alpha.7/ttf/sdl_ttf.go:332 +0x96 fp=0xc000133d50 sp=0xc000133d08 pc=0x108573f36
github.com/veandco/go-sdl2/ttf.(*Font).RenderUTF8BlendedWrapped(0xc000015de8, {0x1085a879e?, 0xc000133de0?}, {0x0?, 0x83?, 0x20?, 0x0?}, 0x0)
	/Users/shello/go/pkg/mod/github.com/veandco/go-sdl2@v0.5.0-alpha.7/ttf/sdl_ttf.go:332 +0xa9 fp=0xc000133db8 sp=0xc000133d50 pc=0x108573da9
nomir/client-sdl2/render.(*FontTexture).makecache.func1()
	/Users/shello/Workspace/me/nomir-2023/client-sdl2/render/texture.font.go:123 +0x128 fp=0xc000133e30 sp=0xc000133db8 pc=0x10857ada8
github.com/veandco/go-sdl2/sdl.Main.func1.1()
	/Users/shello/go/pkg/mod/github.com/veandco/go-sdl2@v0.5.0-alpha.7/sdl/sdl.go:88 +0x22 fp=0xc000133e58 sp=0xc000133e30 pc=0x10850cec2
github.com/veandco/go-sdl2/sdl.Main(0xc000012360)
	/Users/shello/go/pkg/mod/github.com/veandco/go-sdl2@v0.5.0-alpha.7/sdl/sdl.go:101 +0xe5 fp=0xc000133e88 sp=0xc000133e58 pc=0x10850cd65
nomir/client-sdl2/widget_test.TestMain(0xc00007efa0)
	/Users/shello/Workspace/me/nomir-2023/client-sdl2/widget/widget.list_test.go:27 +0x72 fp=0xc000133eb0 sp=0xc000133e88 pc=0x108594d32
main.main()
	_testmain.go:61 +0xa8 fp=0xc000133f50 sp=0xc000133eb0 pc=0x108597bc8
runtime.main()
	/usr/local/go/src/runtime/proc.go:272 +0x28b fp=0xc000133fe0 sp=0xc000133f50 pc=0x1083948cb
runtime.goexit({})
	/usr/local/go/src/runtime/asm_amd64.s:1700 +0x1 fp=0xc000133fe8 sp=0xc000133fe0 pc=0x1083d2741

[shellohunter]

it turned out TTF_RenderUTF8_Solid also crashes if testing long enough, (like half an hour). while TTF_RenderUTF8_Blended_Wrapped will crash in seconds with the same testcase.

does these 2 funcs have builtin threads, or they have access to some shared memory? that may explain something.

[slouken]

No, there's no built in threading and all use of a single font needs to happen on the same thread.