search

sqweek / dialog

Simple cross-platform dialog API for go-lang
ISC License
493 stars 76 forks source link

GTK3 segmentation fault (fedora) #51

Closed hfabre closed 2 years ago

hfabre commented 3 years ago

Hi, thanks for your work !

I'm running into a weird issue, I'm writing a gui application and when I click my button to open the file dialog it segfault. The thing that is very weird is that if at the start of my application (before running the main loop) i'm opening a file dialog it does it successfully and my button works after that (looks like gtk needs a warm up :smile: )

My call looks like that: tscw.newPath, _ = dialog.File().Load()

Here is the stacktrace:

[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7f2d123ced74]

runtime stack:
runtime.throw(0x97b720, 0x2a)
    /usr/lib/golang/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
    /usr/lib/golang/src/runtime/signal_unix.go:679 +0x46a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x867f10, 0xc000129930, 0x3962400)
    /usr/lib/golang/src/runtime/cgocall.go:133 +0x5b fp=0xc000129900 sp=0xc0001298c8 pc=0x49c38b
github.com/gotk3/gotk3/gtk._Cfunc_gtk_dialog_run(0x3962400, 0x0)
    _cgo_gotypes.go:8410 +0x49 fp=0xc000129930 sp=0xc000129900 pc=0x5d2119
github.com/gotk3/gotk3/gtk.(*Dialog).Run.func1(0xc00017f9b0, 0xc00017f901)
    /home/hfabre/go/pkg/mod/github.com/gotk3/gotk3@v0.4.0/gtk/gtk.go:2963 +0x5b fp=0xc000129968 sp=0xc000129930 pc=0x66c1bb
github.com/gotk3/gotk3/gtk.(*Dialog).Run(0xc00017f9b0, 0x1)
    /home/hfabre/go/pkg/mod/github.com/gotk3/gotk3@v0.4.0/gtk/gtk.go:2963 +0x2b fp=0xc000129988 sp=0xc000129968 pc=0x6238db
github.com/sqweek/dialog.chooseFile(0x974039, 0x9, 0x97362c, 0x4, 0x0, 0xc000129ba8, 0x0, 0x0, 0x0, 0x0)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs_linux.go:79 +0x37c fp=0xc000129af8 sp=0xc000129988 pc=0x7a002c
github.com/sqweek/dialog.(*FileBuilder).load(...)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs_linux.go:45
github.com/sqweek/dialog.(*FileBuilder).Load(0xc000129ba8, 0x41c8000042960000, 0x975033, 0xe, 0x101)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs.go:112 +0x62 fp=0xc000129b58 sp=0xc000129af8 pc=0x79fb12
ttme/src.(*tilesetConfigurationWidget).Draw(0xc000129df0)
    /home/hfabre/local/go/ttme/src/tleset_configuration_widget.go:27 +0x341 fp=0xc000129bf0 sp=0xc000129b58 pc=0x7a3501
ttme/src.(*app).Start(0xc000074480)
    /home/hfabre/local/go/ttme/src/app.go:71 +0x326 fp=0xc000129f50 sp=0xc000129bf0 pc=0x7a08a6
main.main()
    /home/hfabre/local/go/ttme/main.go:9 +0x56 fp=0xc000129f88 sp=0xc000129f50 pc=0x7a46a6
runtime.main()
    /usr/lib/golang/src/runtime/proc.go:203 +0x1fa fp=0xc000129fe0 sp=0xc000129f88 pc=0x4cd06a
runtime.goexit()
    /usr/lib/golang/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc000129fe8 sp=0xc000129fe0 pc=0x4f7af1
exit status 2
make: *** [Makefile:4: run] Error 1

I feel like it's not very clear, ping me if you don't understand

sqweek commented 3 years ago

Maybe try a newer gotk3, gotk3/gotk3#593 was fixed since v0.4.0

hfabre commented 3 years ago

Not very familiar with Go nor go modules but looking at my go.mod looks like I'm already on v0.4.0:

module ttme

go 1.13

require (
    github.com/gotk3/gotk3 v0.4.0 // indirect
    github.com/lachee/raylib-goplus v0.0.0-20200605081007-7ca39b8afc71
    github.com/sqweek/dialog v0.0.0-20200601143742-43ea34326190
)

I guess I should try using gtk3 upstream but I really don't know how to do, any ideas ?

sqweek commented 3 years ago

Yes, I mean the gotk3 fix happened after v0.4.0 -- 114 commits later to be exact. They haven't made a newer release yet, but there must be a way to ask go mod for a specific commit, see if you can try it with b248c84

hfabre commented 3 years ago

Just tried with

    github.com/gotk3/gotk3 v0.4.1-0.20200606044958-b248c84e8b17 // indirect

But it looks like the problem is still here:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7f08f1e58d74]

runtime stack:
runtime.throw(0x9b68fb, 0x2a)
    /usr/lib/golang/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
    /usr/lib/golang/src/runtime/signal_unix.go:679 +0x46a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x895ee0, 0xc0000dd7d0, 0x29da450)
    /usr/lib/golang/src/runtime/cgocall.go:133 +0x5b fp=0xc0000dd7a0 sp=0xc0000dd768 pc=0x4a3fcb
github.com/gotk3/gotk3/gtk._Cfunc_gtk_dialog_run(0x29da450, 0x0)
    _cgo_gotypes.go:9356 +0x49 fp=0xc0000dd7d0 sp=0xc0000dd7a0 pc=0x5ed349
github.com/gotk3/gotk3/gtk.(*Dialog).Run.func1(0xc000164310, 0xc000164201)
    /home/hfabre/go/pkg/mod/github.com/gotk3/gotk3@v0.4.1-0.20200606044958-b248c84e8b17/gtk/gtk.go:2968 +0x5b fp=0xc0000dd808 sp=0xc0000dd7d0 pc=0x69017b
github.com/gotk3/gotk3/gtk.(*Dialog).Run(0xc000164310, 0x1)
    /home/hfabre/go/pkg/mod/github.com/gotk3/gotk3@v0.4.1-0.20200606044958-b248c84e8b17/gtk/gtk.go:2968 +0x2b fp=0xc0000dd828 sp=0xc0000dd808 pc=0x64248b
github.com/sqweek/dialog.chooseFile(0x9af195, 0x9, 0x9ae77c, 0x4, 0x0, 0xc0000dda48, 0x0, 0x0, 0x0, 0x0)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs_linux.go:79 +0x37c fp=0xc0000dd998 sp=0xc0000dd828 pc=0x7cb7ec
github.com/sqweek/dialog.(*FileBuilder).load(...)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs_linux.go:45
github.com/sqweek/dialog.(*FileBuilder).Load(0xc0000dda48, 0x41c8000042960000, 0x9b01b4, 0xe, 0x3f800001)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200601143742-43ea34326190/dlgs.go:112 +0x62 fp=0xc0000dd9f8 sp=0xc0000dd998 pc=0x7cb2d2
ttme/src.(*tilesetConfigurationWidget).Draw(0xc0000ddce0, 0xc000110000)
    /home/hfabre/local/go/ttme/src/tleset_configuration_widget.go:28 +0x352 fp=0xc0000dda90 sp=0xc0000dd9f8 pc=0x7d08a2
ttme/src.(*app).Start(0xc00009a510)
    /home/hfabre/local/go/ttme/src/app.go:78 +0x583 fp=0xc0000ddf50 sp=0xc0000dda90 pc=0x7cc2c3
main.main()
    /home/hfabre/local/go/ttme/main.go:9 +0x56 fp=0xc0000ddf88 sp=0xc0000ddf50 pc=0x7d1da6
runtime.main()
    /usr/lib/golang/src/runtime/proc.go:203 +0x1fa fp=0xc0000ddfe0 sp=0xc0000ddf88 pc=0x4d4caa
runtime.goexit()
    /usr/lib/golang/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc0000ddfe8 sp=0xc0000ddfe0 pc=0x4ff731
exit status 2
make: *** [Makefile:4: run] Error 1
sqweek commented 3 years ago

Ok, thanks for trying. Still looks like gotk3's fault; I'm kind of wishing I hadn't been convinced to switch to gtk3 but I'll try to make time on the weekend to see what's going wrong.

hfabre commented 3 years ago

Don't have my laptop for a week but if you need any help testing later I'm in. Le 10 sept. 2020 6:25 PM, sqweek notifications@github.com a écrit : Ok, thanks for trying. Still looks like gotk3's fault; I'm kind of wishing I hadn't been convinced to switch to gtk3 but I'll try to make time on the weekend to see what's going wrong.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

sqweek commented 3 years ago

Ok I tried to bisect gotk3 but half their commits don't build against gtk 3.10 so I gave up. Not that I could reproduce the failure with v0.4.0, but anyway it's not like dialog needs to depend on such a comprehensive wrapper for the tiny area of gtk it touches, so I've removed the gotk3 dependency altogether. Please let me know if you encounter new problems!

hfabre commented 3 years ago

Hi there just came back from holidays sorry.

I still encounter the bug with version github.com/sqweek/dialog v0.0.0-20200911184034-8a3d98e8211d

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

runtime stack:
runtime.throw(0x5c518f, 0x2a)
    /usr/lib/golang/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
    /usr/lib/golang/src/runtime/signal_unix.go:679 +0x46a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x58a390, 0xc00012f700, 0xfffffffd00000000)
    /usr/lib/golang/src/runtime/cgocall.go:133 +0x5b fp=0xc00012f6d0 sp=0xc00012f698 pc=0x42edbb
github.com/sqweek/dialog._Cfunc_gtk_dialog_run(0x2c5a3b0, 0x0)
    _cgo_gotypes.go:229 +0x49 fp=0xc00012f700 sp=0xc00012f6d0 pc=0x4c6849
github.com/sqweek/dialog.chooseFile.func11(0x2c5a3b0, 0x0)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:93 +0x4d fp=0xc00012f730 sp=0xc00012f700 pc=0x4c7ccd
github.com/sqweek/dialog.chooseFile(0x5bf140, 0x9, 0x5be910, 0x4, 0x41c8000000000000, 0xc00012fa48, 0x0, 0x0, 0x0, 0x0)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:93 +0x3b6 fp=0xc00012f998 sp=0xc00012f730 pc=0x4c7326
github.com/sqweek/dialog.(*FileBuilder).load(...)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:55
github.com/sqweek/dialog.(*FileBuilder).Load(0xc00012fa48, 0x41c8000042960000, 0x5bfd4a, 0xe, 0x3f800001)
    /home/hfabre/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs.go:112 +0x61 fp=0xc00012f9f8 sp=0xc00012f998 pc=0x4c65a1
ttme/src.(*tilesetConfigurationWidget).Draw(0xc00012fce0, 0xc000128000)
    /home/hfabre/local/go/ttme/src/tileset_configuration_widget.go:28 +0x352 fp=0xc00012fa90 sp=0xc00012f9f8 pc=0x4cb062
ttme/src.(*app).Start(0xc00007e150)
    /home/hfabre/local/go/ttme/src/app.go:78 +0x583 fp=0xc00012ff50 sp=0xc00012fa90 pc=0x4c8893
main.main()
    /home/hfabre/local/go/ttme/main.go:9 +0x56 fp=0xc00012ff88 sp=0xc00012ff50 pc=0x4cbde6
runtime.main()
    /usr/lib/golang/src/runtime/proc.go:203 +0x1fa fp=0xc00012ffe0 sp=0xc00012ff88 pc=0x45daca
runtime.goexit()
    /usr/lib/golang/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00012ffe8 sp=0xc00012ffe0 pc=0x4882b1
exit status 2
make: *** [Makefile:4: run] Error 1

Did I missed something ?

sqweek commented 3 years ago

Hm nope, I don't see a reason for the crash. What version of gtk+3 do you have installed?

hfabre commented 3 years ago 
$ pkg-config --modversion gtk+-3.0                                                                                                                                                                                                       
3.24.22

Not sure if this is what you are looking for, just tell me.

sqweek commented 3 years ago

I've investigated the gtk+ source but I still can't see how the NULL dereference happens.

You mention different behaviour depending on whether you have a gtk main loop running or not. gtk_dialog_run also spawns a main loop so it could be a poor interaction somehow between those? Are you running your main loop and the dialog call on different threads, and if so do you know anything about what thread safety gtk+ provides?

I won't get time to look into these questions, but if you are able to isolate a minimal program structure which reproduces the crash I'm happy to debug it.

This is a tangent, but since your app is using gtk already I'd also be interested to know your motivation behind using this dialog package (rather than eg. using gtk dialogs directly) :)

hfabre commented 3 years ago

Hi, I will try to isolate the bug. But I expressed myself poorly, I don't use gtk, I use an immediate mode GUI library that does not support native file dialog, that's why I'm using dialog.

The fact is that if I launch a dialog window before entering my main loop (it is not part of my business, it was just a test) it works and my dialog inside the loop works well but if I don't launch a dialog before entering the main loop, my real dialog segfault

hfabre commented 3 years ago

Hi sqweek, I'm able to reproduce the bug with this gist, I think it's pretty straight forward, feel free to reach me if you have any question.

sqweek commented 3 years ago

Thanks! Unfortunately I don't have an actual linux box at the moment - I develop the gtk side of things on windows using WSL. Apparently there's no windows X server which supports opening a GLFW window and so raylib can't open a window to run your test. Sorry but I don't think I can solve this issue in the short term :(

hfabre commented 3 years ago

Oh ok, np. The weird thing is that I already used dialog with another raylib binding (in go as well) with success some times ago. I'll try to reproduce to see if it comes from the binding or just with an older version of dialog and I let you know

hfabre commented 3 years ago

Just tried with the old version and the other binding still get the bug (almost sure it worked well a year ago). Same with a fresh gtk+3 install under an Ubuntu. I'm starting to think this is a gtk bug but I really don't know much about it.

gravestench commented 3 years ago

I'm getting this issue on lubuntu 20.04 LTS

            .-/+oossssoo+/-.               dk@pancake 
        `:+ssssssssssssssssss+:`           ---------- 
      -+ssssssssssssssssssyyssss+-         OS: Ubuntu 20.04.1 LTS x86_64 
    .ossssssssssssssssssdMMMNysssso.       Host: NUC6i7KYK H90755-112 
   /ssssssssssshdmmNNmmyNMMMMhssssss/      Kernel: 5.4.0-58-generic 
  +ssssssssshmydMMMMMMMNddddyssssssss+     Uptime: 4 days, 13 hours, 54 mins 
 /sssssssshNMMMyhhyyyyhmNMMMNhssssssss/    Packages: 2993 (dpkg), 10 (snap) 
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Shell: bash 5.0.17 
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   Resolution: 1920x1200, 1920x1200, 1200x1920 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   WM: i3 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   Theme: Arc-Darker [GTK3] 
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   Icons: Adwaita [GTK3] 
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   CPU: Intel i7-6770HQ (8) @ 3.500GHz 
 /sssssssshNMMMyhhyyyyhdNMMMNhssssssss/    GPU: Intel Iris Pro Graphics 580 
  +sssssssssdmydMMMMMMMMddddyssssssss+     Memory: 11420MiB / 32005MiB 
   /ssssssssssshdmNNNNmyNMMMMhssssss/
    .ossssssssssssssssssdMMMNysssso.                               
      -+sssssssssssssssssyyyssss+-                                 
        `:+ssssssssssssssssss+:`
            .-/+oossssoo+/-.

Error log:

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

runtime stack:
runtime.throw(0x74a89e, 0x2a)
        /usr/local/go/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:726 +0x4ac

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x6b7590, 0xc000161a60, 0x0)
        /usr/local/go/src/runtime/cgocall.go:133 +0x5b fp=0xc000161a30 sp=0xc0001619f8 pc=0x44f69b
github.com/sqweek/dialog._Cfunc_gtk_dialog_run(0x1c2a340, 0x0)
        _cgo_gotypes.go:239 +0x49 fp=0xc000161a60 sp=0xc000161a30 pc=0x60ef49
github.com/sqweek/dialog.runMsgDlg.func4(0x1c2a340, 0x1c71da0)
        /home/dk/.go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:39 +0x4d fp=0xc000161a90 sp=0xc000161a60 pc=0x6103cd
github.com/sqweek/dialog.runMsgDlg(0x73b178, 0xb, 0x0, 0x1, 0xc000161b70, 0xc000000000)
        /home/dk/.go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:39 +0x1a9 fp=0xc000161b28 sp=0xc000161a90 pc=0x60fa49
github.com/sqweek/dialog.(*MsgBuilder).info(...)
        /home/dk/.go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:47
github.com/sqweek/dialog.(*MsgBuilder).Info(...)
        /home/dk/.go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs.go:56
github.com/OpenDiablo2/HellSpawner/hsapp.(*App).renderMainMenuBar.func2()
        /home/dk/src/hellspawner-gravestench/hsapp/app.go:99 +0xfb fp=0xc000161ba0 sp=0xc000161b28 pc=0x61285b
github.com/AllenDang/giu.(*MenuItemWidget).Build(0xc0001c90a0)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/Widgets.go:876 +0x74 fp=0xc000161be0 sp=0xc000161ba0 pc=0x60b814
github.com/AllenDang/giu.Layout.Build(0xc0001c4ce0, 0x1, 0x1)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/Layout.go:11 +0x5a fp=0xc000161c08 sp=0xc000161be0 pc=0x609ada
github.com/AllenDang/giu.(*MenuWidget).Build(0xc0001ce2d0)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/Widgets.go:902 +0x85 fp=0xc000161c38 sp=0xc000161c08 pc=0x60b8a5
github.com/AllenDang/giu.Layout.Build(0xc000161d18, 0x3, 0x3)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/Layout.go:11 +0x5a fp=0xc000161c60 sp=0xc000161c38 pc=0x609ada
github.com/AllenDang/giu.(*MainMenuBarWidget).Build(0xc000161d00)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/Widgets.go:836 +0x68 fp=0xc000161c88 sp=0xc000161c60 pc=0x60b788
github.com/OpenDiablo2/HellSpawner/hsapp.(*App).renderMainMenuBar(0xc00007ced0)
        /home/dk/src/hellspawner-gravestench/hsapp/app.go:102 +0x3a6 fp=0xc000161d58 sp=0xc000161c88 pc=0x611dc6
github.com/OpenDiablo2/HellSpawner/hsapp.(*App).render(0xc00007ced0)
        /home/dk/src/hellspawner-gravestench/hsapp/app.go:49 +0x2f fp=0xc000161d88 sp=0xc000161d58 pc=0x61134f
github.com/OpenDiablo2/HellSpawner/hsapp.(*App).render-fm()
        /home/dk/src/hellspawner-gravestench/hsapp/app.go:48 +0x2a fp=0xc000161da0 sp=0xc000161d88 pc=0x61294a
github.com/AllenDang/giu.(*MasterWindow).render(0xc000159420)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MasterWindow.go:170 +0x96 fp=0xc000161e20 sp=0xc000161da0 pc=0x60acd6
github.com/AllenDang/giu.(*MasterWindow).run.func1()
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MasterWindow.go:189 +0x59 fp=0xc000161e60 sp=0xc000161e20 pc=0x60c2b9
github.com/AllenDang/giu.Call.func1()
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MainThread.go:67 +0x2f fp=0xc000161e90 sp=0xc000161e60 pc=0x60c22f
github.com/AllenDang/giu.Run(0xc00000e5e0)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MainThread.go:53 +0x72 fp=0xc000161ec8 sp=0xc000161e90 pc=0x60a092
github.com/AllenDang/giu.(*MasterWindow).Main(0xc000159420, 0xc00016bda0)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MasterWindow.go:236 +0x65 fp=0xc000161ee8 sp=0xc000161ec8 pc=0x60afe5
github.com/OpenDiablo2/HellSpawner/hsapp.(*App).Run(0xc00007ced0)
        /home/dk/src/hellspawner-gravestench/hsapp/app.go:45 +0xec fp=0xc000161f48 sp=0xc000161ee8 pc=0x6112ec
main.main()
        /home/dk/src/hellspawner-gravestench/main.go:16 +0x85 fp=0xc000161f88 sp=0xc000161f48 pc=0x6129e5
runtime.main()
        /usr/local/go/src/runtime/proc.go:204 +0x209 fp=0xc000161fe0 sp=0xc000161f88 pc=0x483dc9
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc000161fe8 sp=0xc000161fe0 pc=0x4b4c01

goroutine 6 [chan receive]:
github.com/AllenDang/giu.Call(0xc0001ce210)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MainThread.go:68 +0xaa
github.com/AllenDang/giu.(*MasterWindow).run(0xc000159420)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MasterWindow.go:187 +0x74
github.com/AllenDang/giu.(*MasterWindow).Main.func1()
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MasterWindow.go:241 +0x4d
github.com/AllenDang/giu.Run.func1(0xc00000e5e0, 0xc0000720c0)
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MainThread.go:50 +0x27
created by github.com/AllenDang/giu.Run
        /home/dk/.go/pkg/mod/github.com/!allen!dang/giu@v0.4.2/MainThread.go:50 +0x6b
exit status 2

I'm pretty sure I have the dependencies met.

I've installed the following:

gravestench commented 3 years ago

FYI We just needed to be able to init gtk manually.

This was some kind of threading issue for us. The fix was to export the init func in dlgs_linux.go and add no-op init funcs to the windows and darwin versions.

sqweek commented 3 years ago

@gravestench Oh hm, thanks for the info!

After a little reading, it seems that the GTK API (especially since 3.6) mandates that all calls happen within the "main" thread, ie. the one running gtk_main. Which is tricky from dialog's perspective because such a thread may not exist. Clearly it is not strictly necessary or dialog would not work at all, but it seems I'm in poorly defined territory. Main reference: https://stackoverflow.com/questions/18941307/calling-gtk-main-under-pthreadsecondary-thread-in-c-code

Regarding your fix, the go runtime guarantees that each module's init function executes on the primordial thread. If I'm reading correctly you've moved the gtk_init call so it happens within hsapp.(*App).Run, which ... also runs on the primordial thread? Do you have any calls into dialogs from other threads/goroutines?

gravestench commented 3 years ago

I'm not really sure why it works, I'm just glad that it does.

essial commented 3 years ago

It's hard to say. We do plenty of dialog calls on callbacks for imgui click events, and we've had 0 issues since making the fix on our fork.

essial commented 3 years ago

Oh and to clarify we do not use GTK directly. We are using an imgui library which, on Linux, initialized a GL context. As stated previously, the fix we made on our fork works and we've had no issues at all with dialog since then.

Nv7-GitHub commented 3 years ago

I am having the same issue, how do you fix this?

sqweek commented 3 years ago

@Nv7-GitHub are you also using an openGL context in conjunction with dialog?

If you follow gravestench's comments you'll find an OpenDiablo2/dialog fork which works around the issue, but it also changes the API (you have to manually call dialog.Init). I haven't found time to look further into a local reproducer or an API-preserving change.

Ziemas commented 3 years ago

I think I ran into this on the OpenDiablo2 fork as well. What I found was that it crashes because a null ptr gets passed to pthread_mutex_lock() somewhere in libX11.

I'm able to get it working by calling XInitThreads() before gtk_init(), not really sure if that is a completely proper solution though.

sqweek commented 2 years ago

Thanks @Ziemas! I'm confused as to why pthread_mutex_lock() or similar doesn't show up in the backtrace, but I've committed a fix based on your suggestion (after another user tested it in #58).

Optimistically closing this.