[Mesa-dev] [Bug 105507] Crash when destroying a newly resized EGLsurface with wayland egl (dri2)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Pekka Paalanen from comment #4)
> (In reply to Daniel Stone from comment #2)
> > You could place any orphaned wl_buffers on an per-surface list instead, and
> > spin at destruction until that emptied.
> 
> What would guarantee that the last committed wl_buffer would actually get
> released at all?
> 
> Destroying the EGLSurface cannot destroy the wl_surface, because the
> wl_surface is caller-owned, isn't it?

Correct, so the only correct (though incredibly counter-intuitive) course of
action is to destroy the wl_surface before destroying the EGLSurface.
Alternately, destroy the wl_surface role object in such a way which guarantees
it's unmapped.

The fact people don't actually do this is why Mesa just immediately destroys
_all_ buffers - released or not - when the EGLSurface is destroyed. If the
buffer hasn't been released, you might catch a client error.

That being said, I was suggesting 'orphaned' wl_buffers: i.e. where they are
still marked busy, but have been discarded from the surface list due to a
resize request. This happens on the first draw call after a surface resize, so
the only point which a buffer could be so orphaned and not have a release
scheduled is if you did: wl_egl_window_resize(); glClear();
eglDestroySurface(); without swapping. Or, I guess, if you were frozen in a
synchronous subsurface.

(I'm really regretting caving in and making it illegal to destroy an unreleased
wl_buffer.)

-- 
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/20180315/37a0c72f/attachment.html>