According to my analysis this is a common issue for those gtk applications that don't depend on GL (so that e.g. libgl1-mesa-glx is not pulled in as a (in)direct dependency).
This is caused by a glXQueryExtension call inside Gtk function gdk_x11_screen_init_gl (gdk/x11/gdkglcontext-x11.c).
IMO ideally would be to detect in runtime if GL is available and skip this call otherwise. My gtk test build with this call commented out (ppa:dgadomski/firefox-lp1550983) seems to work fine.
I've been able to reproduce it also with Firefox, mousetweaks & gtk3-demo launched from a Windows client via cygwin with X on a server image with those apps installed with apt-get (none of them pulls in GLX implementation).
This seemed to work correctly from a Linux client ssh -X to the same machine. The control in this case skips this call - one frame above (_gdk_x11_screen_update_visuals_for_gl) gl visuals are found (from a local environment?) and used, so no crash happens.
According to my analysis this is a common issue for those gtk applications that don't depend on GL (so that e.g. libgl1-mesa-glx is not pulled in as a (in)direct dependency).
This is caused by a glXQueryExtension call inside Gtk function gdk_x11_ screen_ init_gl (gdk/x11/ gdkglcontext- x11.c).
IMO ideally would be to detect in runtime if GL is available and skip this call otherwise. My gtk test build with this call commented out (ppa:dgadomski/ firefox- lp1550983) seems to work fine.
I've been able to reproduce it also with Firefox, mousetweaks & gtk3-demo launched from a Windows client via cygwin with X on a server image with those apps installed with apt-get (none of them pulls in GLX implementation). screen_ update_ visuals_ for_gl) gl visuals are found (from a local environment?) and used, so no crash happens.
This seemed to work correctly from a Linux client ssh -X to the same machine. The control in this case skips this call - one frame above (_gdk_x11_
Will look more into this.