[Bug 50649] New: winecfg crashes with desktop emulation
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(a)winehq.org Reporter: gmascellani(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 Giovanni Mascellani <gmascellani(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |145cfce1135a7e59cc4c89cd05b | |572403f188161 --- Comment #1 from Giovanni Mascellani <gmascellani(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 --- Comment #2 from Giovanni Mascellani <gmascellani(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 --- Comment #3 from Giovanni Mascellani <gmascellani(a)codeweavers.com> --- Created attachment 69362 --> https://bugs.winehq.org/attachment.cgi?id=69362 Failed attempt to reproduce the bug out of Wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 --- Comment #4 from Giovanni Mascellani <gmascellani(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 Giovanni Mascellani <gmascellani(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED --- Comment #5 from Giovanni Mascellani <gmascellani(a)codeweavers.com> --- It is a bug in mesa. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #6 from Bernhard Übelacker <bernhardu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50649 --- Comment #7 from Bernhard Übelacker <bernhardu(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla