<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [Vulkan CTS] crashes in some dEQP-VK.wsi.wayland.* tests" href="https://bugs.freedesktop.org/show_bug.cgi?id=102578#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [Vulkan CTS] crashes in some dEQP-VK.wsi.wayland.* tests" href="https://bugs.freedesktop.org/show_bug.cgi?id=102578">bug 102578</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>Did a little digging and this definitely appears to be a mesa bug. We have a hash table which maps wl_display pointers to a wsi_wl_display struct. The problem is that we keep the wsi_wl_displays around until the instance is destroyed. The tests are destroying the wl_display before Vulkan. This is perfectly valid so long as they don't have any swapchains hanging around. I see three options: 1) Do a bit of reference counting of the wsi_wl_display and destroy it when the last swapchain to use it goes away. This is a bit sub-optimal because part of the reason why we cache it in the first place is so that we can get surface capabilities and then create the swapchain with as few round-trips as possible. 2) Implement a non-trivial VkSurface and store this information in it. We could still end up with extra round-trips but it would provide most of the benefit. However, this will break our driver on old loaders. Maybe we don't care? 3) Just leak the three wl_proxy objects associated with the wsi_wl_display. If an application is doing a lot of CreateInstance and DestroyInstance, then they're either the CTS or a very broken app. wl_proxy objects are small and we can probably get away with the leak. Among those three options I think 2 is probably the best but I'm still a bit undecided.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>