[Mesa-dev] [Bug 106126] eglMakeCurrent does not always ensure dri_drawable->update_drawable_info has been called for a new EGLSurface if another has been created and destroyed first
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Apr 23 09:40:35 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=106126
Timothy Arceri <t_arceri at yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Timothy Arceri <t_arceri at yahoo.com.au> ---
Fixed by:
author Johan Klokkhammer Helsing <johan.helsing at qt.io>
commit dab02dea3411d325a5aee6cda5b581e61396ecc6
st/dri: Fix dangling pointer to a destroyed dri_drawable
If an EGLSurface is created, made current and destroyed, and then a second
EGLSurface is created. Then the second malloc in driCreateNewDrawable may
return the same pointer address the first surface's drawable had.
Consequently, when dri_make_current later tries to determine if it should
update the texture_stamp it compares the surface's drawable pointer against
the drawable in the last call to dri_make_current and assumes it's the same
surface (which it isn't).
When texture_stamp is left unset, then dri_st_framebuffer_validate thinks
it has already called update_drawable_info for that drawable, leaving it
unvalidated and this is when bad things starts to happen. In my case it
manifested itself by the width and height of the surface being unset.
This is fixed this by setting the pointer to NULL before freeing the
surface.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106126
Signed-off-by: Johan Klokkhammer Helsing <johan.helsing at qt.io>
Signed-off-by: Marek Olšák <marek.olsak at amd.com>
Cc: 18.0 18.1 <mesa-stable at lists.freedesktop.org>
--
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180423/7b75c393/attachment.html>
More information about the mesa-dev
mailing list