https://bugs.winehq.org/show_bug.cgi?id=50649
Bug ID: 50649 Summary: winecfg crashes with desktop emulation Product: Wine Version: 6.0-rc6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: gmascellani@codeweavers.com Distribution: ---
STEPS TO REPRODUCE: * Start with a new prefix * Launch winecfg and enable desktop emulation (leave the standard resolution 800x600) * Launch winecfg again; the desktop window appears and disappears after a split second; winecfg window never appears
This happens with both i386 and amd64 builds (did not try a WoW64 build). I am using an up-to-date Debian unstable machine, on a laptop with an Intel iGPU and an NVIDIA Quadro P2000 dGPU. Disabling NVIDIA Vulkan drivers doesn't change anything.
The crash happens inside get_gpu_properties_from_vulkan, in dlls/winex11.drv/xrandr.c. This function creates a Vulkan instance, enumerates Vulkan devices and their properties and then destroys the instance. This happens a few times during a single "wine winecfg" execution. In one of these executions the driver segfaults in vkDestroyInstance. The other calls to vkDestroyInstance are fine. If the call to vkDestroyInstance in X11DRV_vkDestroyInstance is commented out, then the crash doesn't happen any more and winecfg works correctly.
I can't see any Vulkan usage problem and Vulkan validator doesn't detect anything except a couple of issues that are easy to solve and do not fix the problem.
The specific failing instruction is in libvulkan_lvp.so. Addr2line says it is in function util_queue_destroy in file src/util/u_queue.c:97 (in the mesa package), but that line does not correspond to that function in the source code, so addr2line is probably confused and I don't know if anything it says can be believed. Also, this is just the inner frame: I couldn't get a backtrace from the vkDestroyInstance call to the segfaulting instruction. I can get a core dump, but gdb cannot recognize the stack in it, so I get no useful information (not easily at least: I could manually inspect the stack and reconstruct the backtrace, but that's tedious and I haven't tried yet).