| Summary: | gtk+ apps segfault on Xvfb with mesa 13 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Timo Aaltonen <tjaalton> |
| Component: | GLX | Assignee: | mesa-dev |
| Status: | RESOLVED NOTOURBUG | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 13.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Timo Aaltonen
2016-12-08 11:03:48 UTC
Looks like a libepoxy issue : https://github.com/anholt/libepoxy/issues/72 yeah, patching libepoxy fixed it The bug in libepoxy was triggered by mesa, and now it's not just gtk+ but also qt apps that segfault with xvfb. So whatever triggers these in mesa needs to be found out and examined.. To rule out a GTK+/Qt/epoxy/other bug, can we get a simple test app ? With that in place fixing this should be trivial. Quick run on my Arch system seems fine $ export DISPLAY=:10 $ start-stop-daemon --start --quiet --pidfile /tmp/custom_xvfb_10.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :10 -ac -screen 0 1280x1024x24 $ gnome-terminal Some package numbers: gtk3 3.22.4-1 libepoxy 1.3.1-1 mesa 13.0.2-2 xorg-server-xvfb 1.18.4-1 try with -screen 0 1280x1024x8 debian/ubuntu comes with a wrapper called 'xvfb-run' which uses '-screen 0 640x480x8', and changing that to use 24 fixes the segfault. And I've noticed something like gedit to be better for testing this. bisect seems to point to the segfault starting at: commit 2e9e05dfca18c7f09caa40396d6dd4f2b3ddc1d4 Author: Emil Velikov <emil.velikov@collabora.com> Date: Fri Sep 30 11:01:27 2016 +0100 glx: return GL_FALSE from glx_screen_init where applicable. Using 8bpp, not sure if that's supposed to work even ;-) Joking aside, the bisect result is a surprise and from a quick look the only thing that might be wrong on our end is __glXQueryServerString(). If anything else flags up I'm wondering if it's not an xserver issue - namely, it does not advertise any FB/Visuals. Let me try in x8 and see if I can track it down precisely. Almost but not quite: getVisualConfigs() seems to fail since the xserver advertises zero visuals (reply.numVisuals). Which in itself is not at all surprising. For both 24 and 8 bpp glxinfo correctly handle things printing the following error message: name of display: :10 Error: couldn't find RGB GLX visual or fbconfig At the same time, on 24bpp gnome-terminal/gedit we seems to be hitting different codepath, since we don't even get into libGL.so (__glXInitialize). Leaning towards NOTOURBUG, but if anyone has further tips and suggestions I'll gladly hear them out. right, closing again.. at least xvfb-run wrapper should bump the bitdepth so that glx works I'll check the qt/qml thing separately, bumping the bitdepth didn't fix that |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.