GNOME Bugzilla – Bug 775279
early calls to libepoxy cause all gtk3 programs to abort when there is no GL
Last modified: 2017-10-28 13:46:54 UTC
Something apparently changed in recent fedora updates which causes all gtk3 programs to call some libepoxy functions during initialization. Libepoxy, in turn, passes strings it gets from doing GL queries to sscanf to look for version info and wot-not. libepoxy also fails utterly to check for NULL pointers before calling sscanf, so when the display has zero GL support, all programs segfault at start. See: https://bugzilla.redhat.com/show_bug.cgi?id=1395366 for details. Unfortunately, I see no evidence that libepoxy is maintained. In fact there is a year old bug report in the git repo on this same problem.
libepoxy is in maintenance mode — somebody has started picking it up again after Eric (the original author) left it dormant. What kind of X server are you using?
All my problems originate on a fully up to date fedora 24 x86_64 system running fvwm (so NOT gnome and wayland). I have no idea where the fedora folks grab their libepoxy from (or gtk3 for that matter), but I've got all the versions as provided by the official fedora 24 repos.
I should add that the x server where things abort is provided by the x2goclient. There is fine GL support on the native desktop, but the server x2go provides has no GL.
(In reply to Tom Horsley from comment #2) > All my problems originate on a fully up to date fedora 24 x86_64 system > running fvwm (so NOT gnome and wayland). I have no idea where the fedora > folks grab their libepoxy from (or gtk3 for that matter), but I've got all > the versions as provided by the official fedora 24 repos. All of that does not answer the question I asked — what kind of X server are you using; I went to the bug linked and noticed that you use x2go. I'll try to add a check inside GTK+ so we don't have to rely on libepoxy to see if we have GLX support, but I have to say that running an X11 server without GLX, XComposite, and a decent version of XRandR extensions in 2016 sounds like a poor idea to me — see: http://wiki.x2go.org/doku.php/doc:de-compat
In the meantime, you can tell GTK+ to disable all GL checks and uses by exporting `GDK_GL=disable` in your environment.
Hey! GDK_GL=disable does seem to work for the blowing up early case. Things that never worked because they blow up long after the init code (like gnome-control-center) still don't work, too bad there isn't a good way to completely eradicate attempts to use GL for useless cosmetic crap.
(In reply to Tom Horsley from comment #6) > too bad there isn't a good way to > completely eradicate attempts to use GL for useless cosmetic crap. I'm sorry you seem to think GL (or Vulkan) is for "useless cosmetic crap", considering GL is the only rendering API we have going forward, and that GTK+ 4.0 is using it extensively. Hopefully, with everything else aside from GTK+ depending on GL, people will finally fix x2go to work reliably in the XXI century.
(In reply to Tom Horsley from comment #6) > Hey! GDK_GL=disable does seem to work for the blowing up early case. Things > that never worked because they blow up long after the init code (like > gnome-control-center) still don't work, too bad there isn't a good way to > completely eradicate attempts to use GL for useless cosmetic crap. Please try to be polite, even if you don't agree with our implementation choices. We already gave you a workaround for your problem.
Created attachment 343914 [details] [review] gdk/x11: Check if we have access to GL before using GLX API If the platform does not have access to libGL then any call to GL and GLX API through libepoxy will fail with an assertion. Until such time that libepoxy exposes API for us to use, we can simply dlopen libGL ourselves and do a symbol check.
Review of attachment 343914 [details] [review]: ::: gdk/x11/gdkglcontext-x11.c @@ +856,3 @@ + /* This is an ad hoc check that bypasses libepoxy to check if libGL.so is + * available, and disables GL support if that's the case s/available/unavailable/ To match libepoxy logic you might want to wrap this in #if !defined(_WIN32) && !defined(__APPLE__) so the check is skipped on those. (Although people probably shouldn't use X11 there.)
(In reply to Simon McVittie from comment #10) > To match libepoxy logic you might want to wrap this in > > #if !defined(_WIN32) && !defined(__APPLE__) Actually, certainly not _WIN32, and possibly not __APPLE__ either (I have no idea whether OS X normally has GLX).
Review of attachment 343914 [details] [review]: Please commit with the doc fixup
Actually, now that libepoxy is maintained again, I've pushed a fix there. I have to update the libepoxy dependency to 1.4, so I can use `epoxy_has_glx()` in GDK instead of this patch; will attach a new version momentarily.
Created attachment 345898 [details] [review] Bump up the dependency on libepoxy We are going to use new API to detect whether or not GLX is available before calling GL API.
Created attachment 345899 [details] [review] x11: Query whether we have GLX support Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is available on the current system. If we didn't use this API, we'd have to manually dlopen libGL (or its equivalent on different OSes) and check if it had GLX symbols; since Epoxy already does all of this internally, we can simply ask it instead.
Can that be applied for gtk4? Requiring a new libepoxy should be alright there I guess.
Attachment 345898 [details] pushed as 183538c - Bump up the dependency on libepoxy Attachment 345899 [details] pushed as 02eb344 - x11: Query whether we have GLX support