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).
https://bugs.winehq.org/show_bug.cgi?id=50649
Giovanni Mascellani gmascellani@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |145cfce1135a7e59cc4c89cd05b | |572403f188161
--- Comment #1 from Giovanni Mascellani gmascellani@codeweavers.com --- I forgot to mention that the bug was introduced in 145cfce1135a7e59cc4c89cd05b572403f188161, which is the commit that introduced the function get_gpu_properties_from_vulkan (called, at the time, get_vulkan_device_uuid) where the bug happens.
https://bugs.winehq.org/show_bug.cgi?id=50649
--- Comment #2 from Giovanni Mascellani gmascellani@codeweavers.com --- I hadn't realized that libvulkan_lvp.so is the lavapipe Vulkan (software) implementation (once called llvmpipe). Disabling the corresponding ICD made the crash disappear.
Lavapipe has been recently enabled (on my request...) in the Debian mesa package starting from version 20.3.2-1 (see https://tracker.debian.org/media/packages/m/mesa/changelog-20.3.4-1), and is currently in Debian testing, which is staged to be released in a few months. I am not sure about the timing, but it will eventually reach Ubuntu too. Therefore this crash might soon become a problem for many users (unless this also depends on some problem in my local configuration).
I tried to write a little program to reproduce the crash out of Wine (attached), but it doesn't crash.
https://bugs.winehq.org/show_bug.cgi?id=50649
--- Comment #3 from Giovanni Mascellani gmascellani@codeweavers.com --- Created attachment 69362 --> https://bugs.winehq.org/attachment.cgi?id=69362 Failed attempt to reproduce the bug out of Wine
https://bugs.winehq.org/show_bug.cgi?id=50649
--- Comment #4 from Giovanni Mascellani gmascellani@codeweavers.com --- This turned out to be a bug in mesa. I submitted a pull request upstream: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8983.
https://bugs.winehq.org/show_bug.cgi?id=50649
Giovanni Mascellani gmascellani@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Giovanni Mascellani gmascellani@codeweavers.com --- It is a bug in mesa.
https://bugs.winehq.org/show_bug.cgi?id=50649
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- For me this gets triggered when running current wine versions inside firejail, also with desktop mode.
Unfortunately it just prints the "failed to initialize" and because this happens during process creation it is kind of hard to find out where exactly it is crashing or why. Therefore it took me a while to get to this bug.
WINEDEBUG=+pid,+tid,+vulkan,+seh wine winecfg ... 013c:0140:trace:vulkan:X11DRV_vkDestroyInstance 0x7e43b620 (nil) 013c:0140:trace:seh:dispatch_exception code=c0000005 flags=0 addr=749C1543 ip=749c1543 tid=0140 ... 013c:0140:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting 013c:0140:err:module:LdrInitializeThunk Initializing dlls for L"C:\windows\system32\winecfg.exe" failed, status c0000005
A plaing gdb attached shows unfortunately just the last frame, when doing "add-symbol-file /usr/lib/i386-linux-gnu/libvulkan_lvp.so 0x7d46b000" with the address from the executable entry in /proc/$PID/maps:
#0 0x7d5f5543 in draw_prepare_shader_outputs (draw=0x7e92cab0) at ../src/gallium/auxiliary/draw/draw_context.c:676
(I guess the addr2line method would just work if ASLR is disabled.)
As a workaround for me I can add `blacklist /usr/lib/*-linux-gnu/libvulkan.so*` to firejail to make it work, until fixed mesa versions arrive in distributions.
Another workaround, that I found, was renaming the wine-preloader.
https://bugs.winehq.org/show_bug.cgi?id=50649
--- Comment #7 from Bernhard Übelacker bernhardu@mailbox.org --- One short addition: Unfortunately hiding libvulkan_lvp.so* made 3d also not working.
Another and maybe better workaround could be to start with this environment: LP_NUM_THREADS=0 wine winecfg
-
WineHQ Bugzilla