Running gtk+ apps on Xvfb segfault with mesa 13. # DISPLAY=:10 gdb gnome-terminal.real GNU gdb (Ubuntu 7.12-0ubuntu2) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnome-terminal.real...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/gnome-terminal.real [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. rawmemchr () at ../sysdeps/x86_64/rawmemchr.S:37 37 ../sysdeps/x86_64/rawmemchr.S: No such file or directory. (gdb) bt full #0 0x00007ffff5c2c22f in rawmemchr () at ../sysdeps/x86_64/rawmemchr.S:37 #1 0x00007ffff5c14702 in _IO_str_init_static_internal (sf=sf@entry=0x7fffffffdeb0, ptr=ptr@entry=0x0, size=size@entry=0, pstart=pstart@entry=0x0) at strops.c:41 fp = 0x7fffffffdeb0 end = <optimized out> #2 0x00007ffff5c01b97 in __GI___isoc99_vsscanf (string=0x0, format=0x7ffff459d2f2 "%d.%d", args=args@entry=0x7fffffffdfd8) at isoc99_vsscanf.c:41 ret = -168479552 sf = {_sbf = {_f = {_flags = -72515584, _IO_read_ptr = 0x0, _IO_read_end = 0x0, _IO_read_base = 0x0, _IO_write_base = 0x0, _IO_write_ptr = 0x0, _IO_write_end = 0x0, _IO_buf_base = 0x0, _IO_buf_end = 0x0, _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 1279729765, _flags2 = 0, _old_offset = 8247626353045954392, _cur_column = 0, _vtable_offset = 0 '\000', _shortbuf = "", _lock = 0x0, _offset = 8243124844846729043, _codecvt = 0x636572705f786574, _wide_data = 0xffffffffffffffff, _freeres_list = 0x0, _freeres_buf = 0x6c636572705f7865, __pad5 = 2338615505513836649, _mode = -1, _unused2 = '\000' <repeats 12 times>, "GL_ARB_d"}, vtable = 0x7ffff5f534c0 <_IO_str_jumps>}, _s = {_allocate_buffer = 0x0, _free_buffer = 0x0}} #3 0x00007ffff5c01b37 in __isoc99_sscanf (s=<optimized out>, format=format@entry=0x7ffff459d2f2 "%d.%d") at isoc99_sscanf.c:31 arg = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fffffffe0b0, reg_save_area = 0x7fffffffdff0}} done = -168479552 #4 0x00007ffff457fd22 in epoxy_glx_version (dpy=dpy@entry=0x555555794800, screen=screen@entry=0) at dispatch_glx.c:60 server_major = 1434011648 server_minor = 150 client_major = 157 client_minor = 95 server = <optimized out> client = <optimized out> version_string = <optimized out> ret = <optimized out> __PRETTY_FUNCTION__ = "epoxy_glx_version" #5 0x00007ffff722fb49 in gdk_x11_screen_init_gl (screen=screen@entry=0x5555557a8030 [GdkX11Screen]) at ././gdk/x11/gdkglcontext-x11.c:866 display = 0x5555557a10f0 [GdkX11Display] display_x11 = 0x5555557a10f0 [GdkX11Display] dpy = 0x555555794800 error_base = 157 event_base = 95 screen_num = 0 __func__ = "gdk_x11_screen_init_gl" #6 0x00007ffff722fefa in _gdk_x11_screen_update_visuals_for_gl (screen=screen@entry=0x5555557a8030 [GdkX11Screen]) at ././gdk/x11/gdkglcontext-x11.c:1210 x11_screen = 0x5555557a8030 [GdkX11Screen] display = 0x5555557a10f0 [GdkX11Display] display_x11 = 0x5555557a10f0 [GdkX11Display] dpy = 0x555555794800 gl_info = <optimized out> i = <optimized out> system_visual_id = <optimized out> rgba_visual_id = <optimized out> #7 0x00007ffff7238ac6 in _gdk_x11_screen_init_visuals (screen=screen@entry=0x5555557a8030 [GdkX11Screen]) at ././gdk/x11/gdkvisual-x11.c:309 possible_depths = {32, 30, 24, 16, 15, 8, 4, 1} possible_types = {GDK_VISUAL_DIRECT_COLOR, GDK_VISUAL_TRUE_COLOR, GDK_VISUAL_PSEUDO_COLOR, GDK_VISUAL_STATIC_COLOR, GDK_VISUAL_GRAYSCALE, GDK_VISUAL_STATIC_GRAY} x11_screen = 0x5555557a8030 [GdkX11Screen] visual_list = <optimized out> visual_template = {visual = 0x0, visualid = 93824994654928, screen = 0, depth = 21845, class = 461, red_mask = 93824994592768, green_mask = 5728978944, blue_mask = 0, colormap_size = 0, bits_per_rgb = 0} temp_visual = <optimized out> default_xvisual = <optimized out> visuals = 0x5555557a37c0 nxvisuals = 6 nvisuals = <optimized out> i = <optimized out> j = <optimized out> __func__ = "_gdk_x11_screen_init_visuals" #8 0x00007ffff7235b36 in _gdk_x11_screen_new (display=display@entry=0x5555557a10f0 [GdkX11Display], screen_number=0) at ././gdk/x11/gdkscreen-x11.c:908 screen = 0x5555557a8030 [GdkX11Screen] x11_screen = 0x5555557a8030 [GdkX11Screen] display_x11 = 0x5555557a10f0 [GdkX11Display] scale_str = <optimized out> #9 0x00007ffff7225a48 in _gdk_x11_display_open (display_name=<optimized out>) at ././gdk/x11/gdkdisplay-x11.c:1416 xdisplay = <optimized out> display = 0x5555557a10f0 [GdkX11Display] display_x11 = 0x5555557a10f0 [GdkX11Display] attr = {title = 0x5 <error: Cannot access memory at address 0x5>, event_mask = 0, x = 0, y = 0, width = 0, height = 0, wclass = GDK_INPUT_OUTPUT, visual = 0x0, window_type = GDK_WINDOW_ROOT, cursor = 0x0, wmclass_name = 0x0, wmclass_class = 0x0, override_redirect = 636884480, type_hint = 2756754191} argc = <optimized out> argv = {0x43 <error: Cannot access memory at address 0x43>} class_hint = <optimized out> pid = 1 ignore = 147 maj = 1966042741 min = 796026227 __func__ = "_gdk_x11_display_open" #10 0x00007ffff71fa495 in gdk_display_manager_open_display (manager=<optimized out>, name=0x0) at ././gdk/gdkdisplaymanager.c:472 backend = 0x555555792d70 "*" any = 1 backend_list = <optimized out> display = 0x0 backends = 0x555555792d90 i = <optimized out> allow_any = 1 __func__ = "gdk_display_manager_open_display" #11 0x00007ffff76f5e66 in post_parse_hook (context=<optimized out>, group=<optimized out>, data=0x55555578d5e0, error=0x7fffffffe608) at ././gtk/gtkmain.c:801 info = 0x55555578d5e0 #12 0x00007ffff670eb48 in g_option_context_parse (context=<optimized out>, argc=0x7fffffffe5fc, argv=<optimized out>, error=<optimized out>) at ././glib/goption.c:2165 group = <optimized out> i = 1 j = <optimized out> k = <optimized out> list = 0x55555578e600 #13 0x000055555555ce94 in () #14 0x000055555555a0a6 in () #15 0x00007ffff5bb53f1 in __libc_start_main (main= 0x555555559fd0, argc=1, argv=0x7fffffffe7d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe7c8) at ../csu/libc-start.c:291 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 2632460885428681959, 93824992257968, 140737488349136, 0, 0, 8204771725397081319, 8204750245572394215}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fffffffe7e8, 0x7ffff7ffe168}, data = {prev = 0x0, cleanup = 0x0, canceltype = -6168}}} not_first_call = <optimized out> #16 0x000055555555a7da in () This is a regression since mesa 12.
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.