<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Crash when destroying a newly resized EGLsurface with wayland egl (dri2)" href="https://bugs.freedesktop.org/show_bug.cgi?id=105507#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Crash when destroying a newly resized EGLsurface with wayland egl (dri2)" href="https://bugs.freedesktop.org/show_bug.cgi?id=105507">bug 105507</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Daniel Stone from <a href="show_bug.cgi?id=105507#c5">comment #5</a>) > 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. I would not like that. You create wl_surface, then wl_egl_surface, then EGLSurface, and destroy them in the exact opposite order. That's the only sane thing I can imagine. Otherwise various places will hold stale pointers, even if you could trust on your luck that those pointers will not be dereferenced when destroying the other bits. > 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. A client misbehaviour more like. It would be good to have the app unmap the window before the EGLSurface gets destroyed, but I don't think we can make that a hard requirement anymore. To me it seems perfectly logical that destroying the EGLSurface will release all framebuffer resources. > 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 don't think it's realistic to ban such sequences. The very least, they should not result in a crash. > (I'm really regretting caving in and making it illegal to destroy an > unreleased wl_buffer.) Where was it made illegal? It may just cause a glitch on screen. If it's illegal, we should have compositors raise a fatal protocol error on destroy before release. Is that implemented somewhere? I believe destroying the wl_buffers on EGLSurface destruction regardless whether they were released is the best solution. It allows the EGL to avoid crashes and stale pointers, it does not impose a very awkward and surprising destruction order, and apps still have the chance to guarantee there will not be any glitches by using a role-specific way to unmap the wl_surface before destroying the EGLSurface.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>