Bug 99027 - gtk+ apps segfault on Xvfb with mesa 13
Summary: gtk+ apps segfault on Xvfb with mesa 13
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: 13.0
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-08 11:03 UTC by Timo Aaltonen
Modified: 2016-12-16 09:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timo Aaltonen 2016-12-08 11:03:48 UTC
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.
Comment 1 Lionel Landwerlin 2016-12-08 11:39:57 UTC
Looks like a libepoxy issue : https://github.com/anholt/libepoxy/issues/72
Comment 2 Timo Aaltonen 2016-12-08 12:59:00 UTC
yeah, patching libepoxy fixed it
Comment 3 Timo Aaltonen 2016-12-14 14:06:30 UTC
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..
Comment 4 Emil Velikov 2016-12-14 19:07:00 UTC
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.
Comment 5 Emil Velikov 2016-12-14 19:39:20 UTC
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
Comment 6 Timo Aaltonen 2016-12-14 22:14:04 UTC
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.
Comment 7 Jordan Justen 2016-12-14 23:15:29 UTC
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.
Comment 8 Emil Velikov 2016-12-15 14:43:14 UTC
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.
Comment 9 Emil Velikov 2016-12-15 15:10:09 UTC
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.
Comment 10 Timo Aaltonen 2016-12-16 09:48:19 UTC
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.