[Bug 59677] New: Wine crashes when using zink with Vampire: The Masquerade — Redemption
http://bugs.winehq.org/show_bug.cgi?id=59677 Bug ID: 59677 Summary: Wine crashes when using zink with Vampire: The Masquerade — Redemption Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: shtetldik@gmail.com Distribution: --- It used to work before, but I noticed that now when running Vampire: The Masquerade — Redemption (which is a DX7 game) using zink, it crashes. It does work when using a regular OpenGL driver (radeonsi in my case). It crashes both with Mesa git and Mesa 26.0.4 zink. I was testing it using MESA_LOADER_DRIVER_OVERRIDE='zink' Nothing really stands out in the wine log. Let me know if I should attach it with some specific debug channels. OS: Debian testing GPU: Radeon RX 7900 XTX (crashes with zink→radv, works with radeonsi). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #1 from Shmerl <shtetldik@gmail.com> --- I built Mesa with debug symbols and got some additional errors and stack trace from the core. Could be Mesa bug, so I'll report it there. But just for the reference, here is the error and stack backtrace: ../source/src/gallium/auxiliary/util/u_threaded_context.c:614: tc_add_sized_call: Assertion `!next->closed' failed. Backtrace from the core: Message: Process 50931 (Vampire.exe) of user 1000 dumped core. ... Stack trace of thread 50997: #0 0x00007f42485ba50d abort (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x2850d) #1 0x00007f42485ba424 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x28424) #2 0x00007f42322239b4 tc_add_sized_call (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0xc239b4) #3 0x00007f423222c96a tc_blit_enqueue (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0xc2c96a) #4 0x00007f423222ccf7 tc_blit (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0xc2ccf7) #5 0x00007f4231c2b449 do_blit_framebuffer (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x62b449) #6 0x00007f4231c2bcc5 blit_framebuffer (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x62bcc5) #7 0x00007f4231c2c448 _mesa_BlitFramebuffer (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x62c448) #8 0x00007f42318fd500 _mesa_unmarshal_BlitFramebuffer (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x2fd500) #9 0x00007f42316e3c9d glthread_unmarshal_batch (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0xe3c9d) #10 0x00007f4231e4cd4c util_queue_thread_func (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x84cd4c) #11 0x00007f4231ea5818 impl_thrd_routine (/opt/mesa-main/x86_64/libgallium-26.2.0-devel.so + 0x8a5818) #12 0x00007f4248627da9 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x95da9) #13 0x00007f42486a6e08 n/a (/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x114e08) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #2 from Shmerl <shtetldik@gmail.com> --- Opened Mesa bug here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15335 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #3 from Shmerl <shtetldik@gmail.com> --- Interesting, it still crashes with Wine 11.1 but works with Wine 11.0. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #4 from Shmerl <shtetldik@gmail.com> --- I narrowed it down to these commits and reverting them makes it not crash: win32u: Load glBlitFramebuffer function pointer. opengl32: Fix front buffer emulation glBlitFramebuffer parameters. opengl32: Use glBlitFramebuffer instead of glBlitNamedFramebuffer. opengl32: Resolve default framebuffer before flushing. https://gitlab.winehq.org/wine/wine/-/commit/6cbfa74527fbe69bed05a9f766b26ca... https://gitlab.winehq.org/wine/wine/-/commit/6802b32b3859e3b1c3e59bdb462d373... https://gitlab.winehq.org/wine/wine/-/commit/38aa0927222e6d5783f592f95b76c1d... https://gitlab.winehq.org/wine/wine/-/commit/271ad5250ddc6f49b015957eb58c995... Posted details in Mesa bug tracker too. Hopefully between Wine and zink this can be fixed where needed. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #5 from Shmerl <shtetldik@gmail.com> --- Can anyone please advise, do you think it's a Wine or Mesa bug? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 Béla Gyebrószki <gyebro69@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com --- Comment #6 from Béla Gyebrószki <gyebro69@gmail.com> --- I tested the game with NVK/Mesa-26.0.6 and it crashes at startup with a segmentation fault. This appears to be the same issue reported in bug #59394. Reverting commit 6802b32b alone resolves the issue. Switching from EGL to the GLX backend also works around the issue. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #7 from Shmerl <shtetldik@gmail.com> --- (In reply to Béla Gyebrószki from comment #6)
I tested the game with NVK/Mesa-26.0.6 and it crashes at startup with a segmentation fault. This appears to be the same issue reported in bug #59394. Reverting commit 6802b32b alone resolves the issue.
Switching from EGL to the GLX backend also works around the issue.
Mesa developers suggested that the problem could be that multiple threads are using the same pipe_context simultaneously, which I assume is incorrect since it's not thread safe. I confirmed that (see linked Mesa bug). So may be the issue is on Wine's side after all? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 Shmerl <shtetldik@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |opengl -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #8 from Shmerl <shtetldik@gmail.com> --- Still happens with wine 11.9. Rémi Bernon: Do you think something is wrong in Wine's parallel handling of OpenGL pipe_context or the problem is on Mesa's side? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com --- Comment #9 from Rémi Bernon <rbernon@codeweavers.com> --- I don't know, it's possible that we are trying to make a context current on multiple threads at the same time, but it's something that should be forbidden by the EGL/GLX calls, and we should get an error and nothing should crash even if that's the case. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59677 --- Comment #10 from Shmerl <shtetldik@gmail.com> --- (In reply to Rémi Bernon from comment #9)
I don't know, it's possible that we are trying to make a context current on multiple threads at the same time, but it's something that should be forbidden by the EGL/GLX calls, and we should get an error and nothing should crash even if that's the case.
It somehow doesn't crash and just works with radeonsi for example. I can post this point in the Mesa bug. -- 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