GTK3 segmentation fault (fedora) #51
Comments
|
Maybe try a newer gotk3, gotk3/gotk3#593 was fixed since v0.4.0 |
|
Not very familiar with Go nor go modules but looking at my I guess I should try using gtk3 upstream but I really don't know how to do, any ideas ? |
|
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 |
|
Just tried with But it looks like the problem is still here: |
|
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. |
|
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.
|
|
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! |
|
Hi there just came back from holidays sorry. I still encounter the bug with version Did I missed something ? |
|
Hm nope, I don't see a reason for the crash. What version of gtk+3 do you have installed? |
Not sure if this is what you are looking for, just tell me. |
|
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) :) |
|
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 |
|
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. |
|
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 :( |
|
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 |
|
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. |
|
I'm getting this issue on lubuntu 20.04 LTS Error log: I'm pretty sure I have the dependencies met. I've installed the following:
|
|
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 |
|
@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 Regarding your fix, the go runtime guarantees that each module's |
|
I'm not really sure why it works, I'm just glad that it does. |
|
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. |
|
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. |
|
I am having the same issue, how do you fix this? |
|
@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 |
|
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 I'm able to get it working by calling |
resolves #124 Seems like the problem connected with the issue sqweek/dialog#51 Updated dependency to resolve the problem.
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 😄 )
My call looks like that:
tscw.newPath, _ = dialog.File().Load()Here is the stacktrace:
I feel like it's not very clear, ping me if you don't understand
The text was updated successfully, but these errors were encountered: