[Mesa-dev] [Bug 94752] framebuffer from a destroyed drawable is reused when binding the same context to other drawable

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Mar 29 23:31:34 UTC 2016


https://bugs.freedesktop.org/show_bug.cgi?id=94752

            Bug ID: 94752
           Summary: framebuffer from a destroyed drawable is reused when
                    binding the same context to other drawable
           Product: Mesa
           Version: 11.1
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: gqmelo at gmail.com
        QA Contact: mesa-dev at lists.freedesktop.org

Created attachment 122625
  --> https://bugs.freedesktop.org/attachment.cgi?id=122625&action=edit
program to reproduce the bug

I've been trying to catch a flaky bug when with the following scenario:

- Create useful_window
- Create dummy_window
- Create glxcontext
- glXMakeCurrent(dpy, dummy_window, glxcontext)
- get opengl info
- glXMakeCurrent(dpy, None, NULL)
- XDestroyWindow(dpy, dummy_window)
- glXMakeCurrent(dpy, useful_window, glxcontext)
- render stuff

For the record, I've been debugging this because this is roughly what Qt5 does
when creating a new OpenGL widget (it creates a dummy window just to get the
OpenGL version)

Using the attached C program I could reproduce it most of the time when running
with LIBGL_ALWAYS_INDIRECT=1, mesa 11.1.2 and Xephyr as the X11 server.


After using gdb and printing a lot of debug info, in summary this is what
happens:

- glXMakeCurrent(dpy, dummy_window, glxcontext) creates dri_drawable_dummy
- glXMakeCurrent(dpy, None, NULL) does nothing relevant in this case
- XDestroyWindow(dpy, dummy_window) destroys the dri_drawable_dummy
- glXMakeCurrent(dpy, useful_window, glxcontext) creates dri_drawable_useful,
which sometimes happens to have the same address as dri_drawable_dummy (which
should be ok)
- st_api_make_current calls st_framebuffer_reuse_or_create
- st_framebuffer_reuse_or_create see that st->ctx->WinSysDrawBuffer->iface ==
stfbi and then just reuses the existing fb
- then when reusing this framebuffer the stamp contains the value that was set
when the context was bound to the dummy_window, and nothing is rendered


Please be aware that this bug is not consistent as it depends on the second
dri_drawable being allocated at the same address of the destroyed one. As I got
tired of waiting for the bug to happen on each run, I created a patch that
reproduces the exact behaviour (basically making the dri_drawable static)


I'm also attaching the Xephyr output with my debug messages. Sorry for the
mess, but basically contains the functions being executed and its parameters
indented.


I'm willing to fix this bug myself but I need some advice as I've got stuck
here. I appreciate any help.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160329/7e46417c/attachment.html>


More information about the mesa-dev mailing list