June 2023 - Wine-Bugs - list.winehq.org

[Bug 55129] New: Boost throws c++ exception when creating shared memory
by WineHQ Bugzilla June 24, 2023

June 24, 2023

https://bugs.winehq.org/show_bug.cgi?id=55129 Bug ID: 55129 Summary: Boost throws c++ exception when creating shared memory Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: dlehman25(a)gmail.com Distribution: --- Created attachment 74681 --> https://bugs.winehq.org/attachment.cgi?id=74681 simple c++ repro case boost uses 2 methods to fetch the boot time to build a path for shared memory. code path is chosen with a #define the 2 methods are: - registry key (default): - BootId and optionally additionally HybridBootAnimationTime - https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in… - creates a path like: C:/ProgramData/boost_interprocess/01000000/crash - Eventlog - fetches record for event log start - https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in… - creates a path like: C:/ProgramData/boost_interprocess/1687093260/crash - the event log timestamp is always moments after boot on physical and virtual machines i have access to, although many testbot vms seem to have boot records after the event log start - not sure what the 24 bytes at DataOffset are - seems like overkill to fully implement the event log feature, which generally doesn't seem useful on wine, just for this case it throws a c++ exception if either method fails https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in… pull request to follow -- 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.

1 1

[Bug 55038] New: Please add trixie Debian release to Wine repos
by WineHQ Bugzilla June 24, 2023

June 24, 2023

https://bugs.winehq.org/show_bug.cgi?id=55038 Bug ID: 55038 Summary: Please add trixie Debian release to Wine repos Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Please add trixie distro to the Debian repos for Wine, since Debian trixie was just released. Thanks! -- 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.

1 4

[Bug 55125] New: The 64-bit dinput:hotplug sometimes gets timeouts on Windows 10
by WineHQ Bugzilla June 24, 2023

June 24, 2023

https://bugs.winehq.org/show_bug.cgi?id=55125 Bug ID: 55125 Summary: The 64-bit dinput:hotplug sometimes gets timeouts on Windows 10 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: dinput Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The 64-bit dinput:hotplug sometimes gets timeouts on Windows 10 : hid.c:725: Test failed: 0x800: WaitForSingleObject returned 0x102 or hid.c:725: Test failed: WaitForSingleObject returned 0x102 and/or hotplug.c:400: Test failed: MsgWaitForMultipleObjects returned 0x102 See https://test.winehq.org/data/patterns.html#dinput:hotplug Where 0x102 == WAIT_TIMEOUT These failures only happen on w1064-tsign which is a test configuration with test signing enabled. Furthermore only the 64-bit version has these issues. The oldest instance goes back to 2022-12-20 and these failures have happened almost 3 times per month since. -- 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.

1 1

[Bug 53682] New: wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=53682 Bug ID: 53682 Summary: wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14 Product: Wine Version: 7.14 Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: PuetzKevinA(a)JohnDeere.com Distribution: --- I recently updated our builds to past wine-7.0, and began encountering a wineboot failure on aarch64 > 0040:err:system:user_check_not_lock BUG: holding USER lock(64) > s\system32\rundll32.exe: /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:400: user_check_not_lock: Assertion `0' failed. > 0040:err:seh:call_function_handlers invalid frame 21f410 (0000000000022000-0000000000120000) > 0040:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. After some bisecting, I narrowed this down to being a regression between 7.13 and 7.14, and then further narrowed it to https://source.winehq.org/git/wine.git/commit/d50112b4b6e82782d3924a8dbd443… Somehow the call to KeUserModeCallback( NtUserLoadSysMenu,... ) at https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82… does not properly return. I think that commit is mostly a false lead though, the translation of syscall NtUserCreateWindowEx to a syscall just exposed a latent bug in KeUserModeCallback/__wine_syscall_dispatcher on aarch64, since having NtUserCreateWindowEx be a syscall means KeUserModeCallback can no longer use its "if we have no syscall frame, call the callback directly" simple path https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar… What seems to be actually at fault is that, inside of User32LoadSysMenu (the actual function invoked by KeUserModeCallback), is a call to NtUserCreateMenu - which is *also* a syscall. This call doesn't crash, and in fact all of User32LoadSysMenu runs to completion. But when it goes through __wine_syscall_dispatcher, the stack pointer is restored to be `$sp = arm64_thread_data()->syscall_frame` https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar… - i.e. it points to &callback_frame, back on the stack of KeUserModeCallback. And this is *not* the bottom of the stack; there's compiler-generated prologue/epilogue to restore various non-volatile registers. 0x0000ffffaa0247b4 <KeUserModeCallback+0>: sub sp, sp, #0x450 0x0000ffffaa0247b8 <KeUserModeCallback+4>: stp x29, x30, [sp] 0x0000ffffaa0247bc <KeUserModeCallback+8>: mov x29, sp 0x0000ffffaa0247c0 <KeUserModeCallback+12>: stp x19, x20, [sp, #16] 0x0000ffffaa0247c4 <KeUserModeCallback+16>: stp x21, x22, [sp, #32] 0x0000ffffaa0247c8 <KeUserModeCallback+20>: str w0, [sp, #56] 0x0000ffffaa0247cc <KeUserModeCallback+24>: str x1, [sp, #48] 0x0000ffffaa0247d0 <KeUserModeCallback+28>: str w2, [sp, #60] 0x0000ffffaa0247d4 <KeUserModeCallback+32>: mov x21, x3 0x0000ffffaa0247d8 <KeUserModeCallback+36>: mov x20, x4 0x0000ffffaa0247dc <KeUserModeCallback+40>: add x19, sp, #0x40 // x19=&callback_frame So any code that runs inside this syscall that uses the first 0x40 bytes of stack is trampling these variables in the frame of KeUserModeCallback. Eventually User32LoadSysMenu returns back into KiUserCallbackDispatcher, which passes it into NtCallbackReturn, which does a __wine_longjmp back into the KeUserModeCallback,and we exit from the __wine_setjmp for the second time (returning 0) and get to `return callback_frame.status` https://gitlab.winehq.org/wine/wine/-/blob/wine-7.17/dlls/ntdll/unix/signal…. But then the epilogue starts peeling off the stack => 0x0000ffffaa024864 <+176>: ldr w0, [sp, #1088] 0x0000ffffaa024868 <+180>: ldp x19, x20, [sp, #16] 0x0000ffffaa02486c <+184>: ldp x21, x22, [sp, #32] 0x0000ffffaa024870 <+188>: ldp x29, x30, [sp] 0x0000ffffaa024874 <+192>: add sp, sp, #0x450 0x0000ffffaa024878 <+196>: ret and the link register $x30 = (void *) 0xffffaa024984 <NtCallbackReturn+104>, rather than 0xffffa8f0ccdc <copy_sys_popup+44> as it was when it was pushed in the prologue. It's overwritten several times along the way, but I don't think any of these call sites are at fault; they are just writing to what they think is their own stack frame, unaware that __wine_syscall_dispatcher adjusted $sp to too-high a value and they are overwriting space that belongs to KeUserModeCallback. The specific places that overwrote this entry on the stack were #0 0x0000ffffa8f37a48 in NtUserCallOneParam (arg=0, code=2) at /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:5357 #1 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to 0xffffaa022cf0 <__wine_syscall_dispatcher+272> #0 insert_menu_item (ret_pos=0x21f538, flags=1024, id=4294967295, handle=0x10042) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:438 #1 NtUserThunkedMenuItemInfo (handle=0x10042, pos=4294967295, flags=1024, method=1, info=0x11f528 <opengl_func_names+680>, str=<optimized out>) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:1297 #2 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to NULL and 0x0000ffffaa023a0c in NtCurrentTeb () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449 1449 { (gdb) bt #0 0x0000ffffaa023a0c in NtCurrentTeb () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449 #1 0x0000ffffaa02493c in ntdll_get_thread_data () at /home/yukondev/workspace/wine/dlls/ntdll/unix/unix_private.h:70 #2 arm64_thread_data () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:163 #3 NtCallbackReturn (ret_ptr=0x0, ret_len=0, status=65602) at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:784 #4 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to 0xffffaa02493c <NtCallbackReturn+32>, and then 0xffffaa024978 <NtCallbackReturn+92> , then 0xffffaa024984 <NtCallbackReturn+104> The same sort of thing happens in the x86_64 dispatcher, but there it turns out to be pretty harmless. The key difference is that the function prologue on x86_64 used `push` instructions, and did so prior to the `sub` where it allocated space for locals, so the things popped by the epilogue ended up above callback_frame, rather than below it, and so are not smashed. 0x00007fd17b6dc1d2 <+0>: push %rbp 0x00007fd17b6dc1d3 <+1>: mov %rsp,%rbp 0x00007fd17b6dc1d6 <+4>: push %r14 0x00007fd17b6dc1d8 <+6>: push %r13 0x00007fd17b6dc1da <+8>: push %r12 0x00007fd17b6dc1dc <+10>: push %rdi 0x00007fd17b6dc1dd <+11>: push %rsi 0x00007fd17b6dc1de <+12>: push %rbx 0x00007fd17b6dc1df <+13>: sub $0xa0,%rsp 0x00007fd17b6dc1e6 <+20>: and $0xffffffffffffffc0,%rsp 0x00007fd17b6dc1ea <+24>: sub $0x560,%rsp There is still a 32-byte gap between the $rsp of KeUserModeCallback and &current_frame that is briefly at risk, but 1. This seems to be the register parameter area of the Windows x64 ABI, which is actually volatile space that belongs to the callee even though it's allocated by the caller, so the compiler is not expecting it to survive across function calls (in this case __wine_syscall_dispatcher_return). https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170 discusses how this "contains at least 4 entries", i.e. 32 bytes: https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64 2. It doesn't actually get smashed, because __wine_syscall_dispatcher subtracts 0x20 from the restored $rsp before actually making the syscall (https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…) Which is presumably since the SysV ABI does *not* make any such reservation, and so __wine_syscall_dispatcher needs to do so to be following the ms_abi. So together, these mean that on x86_64, it would be OK if __wine_syscall_dispatcher used these 32 bytes between the correct $rsp of KeUserModeCallback and frame->syscall_table (though it doesn't seem to). And the eventual callee gets a $rsp that does *not* overlap with KeUserModeCallback (even though it would be legal for it to do so). I don't know that we have any actual guarantee that callback_frame will be at the bottom, but in practice it seems to be. But on aarch64, there's important stuff below callback_frame, so this doesn't work out. -- 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.

1 29

[Bug 55016] New: xaudio2_8:xaudio2 - test_simple_streaming() crashes on Windows 8+
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=55016 Bug ID: 55016 Summary: xaudio2_8:xaudio2 - test_simple_streaming() crashes on Windows 8+ Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com xaudio2_8:xaudio2 - test_simple_streaming() crashes on Windows 8+: xaudio2.c:339: Test failed: Got hr 0x80004002. xaudio2.c:339: this is the last test seen before the exception 13dc:xaudio2: unhandled exception c0000005 at 00402D6A See https://test.winehq.org/data/patterns.html#xaudio2_8:xaudio2 A bisect shows that the failures started with this commit: commit 14c44d0b0a2fc0ead5bc75615864ff850a44c4d5 Author: Zebediah Figura <zfigura(a)codeweavers.com> Date: Mon Apr 24 16:59:08 2023 -0500 xaudio2: Use the preprocessor to modify definitions in xaudio2.idl and xaudio2fx.idl. Instead of including the IDLs directly, define a local IDL that #includes them, with XAUDIO2_VER defined, and include that generated header. Get rid of compat.c, and use XAUDIO2_VER to modify the code in the other source files. Build the tests for both xaudio2_7 and xaudio2_8 using PARENTSRC, and use XAUDIO2_VER to select between them. This mirrors the approach taken for d3dcompiler, and makes it easier to test more xaudio2 versions in the future. -- 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.

1 4

[Bug 55013] New: user32:monitor - test_EnumDisplayMonitors() sometimes fails on Linux
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=55013 Bug ID: 55013 Summary: user32:monitor - test_EnumDisplayMonitors() sometimes fails on Linux Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:monitor - test_EnumDisplayMonitors() sometimes fails on Linux: monitor.c:1613: Test failed: SetThreadDesktop failed, error 0xaa. monitor.c:1614: Test failed: Expected 00000014, got 00000140. See https://test.winehq.org/data/patterns.html#user32:monitor A bisect shows that the failures started with the commit below: commit 5bdbbee6f4a874159f2e527f39f071547c513ee4 Author: Rémi Bernon <rbernon(a)codeweavers.com> AuthorDate: Fri May 26 19:50:57 2023 +0200 winex11: Rely on win32u to reset clipping on display mode change. -- 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.

1 4

[Bug 54980] New: Times font missing in font list (several programs)
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=54980 Bug ID: 54980 Summary: Times font missing in font list (several programs) Product: Wine Version: 8.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineps.drv Assignee: wine-bugs(a)winehq.org Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de Distribution: --- After this commit, the font "Times" (one of the Postscript base fonts) is missing: a6cb10bba2d05ceca6ba5b1411c450d38defdbb4 is the first bad commit commit a6cb10bba2d05ceca6ba5b1411c450d38defdbb4 Author: Piotr Caban <piotr(a)codeweavers.com> Date: Mon May 15 17:34:23 2023 +0200 wineps: Don't pass PRINTERINFO structure to unixlib. dlls/wineps.drv/init.c | 5 +- dlls/wineps.drv/unixlib.c | 310 +++++----------------------------------------- dlls/wineps.drv/unixlib.h | 5 +- 3 files changed, 35 insertions(+), 285 deletions(-) This happens in several programs (Framemaker 8, Office 2007). The result is, that in documents which use this font it is replaced (in most cases by "Times New Roman") but this does not work always and not good for font variants like "Times Bold". -- 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.

1 11

[Bug 54442] New: experimental wow64 mode: doesn't show some graphical windows
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=54442 Bug ID: 54442 Summary: experimental wow64 mode: doesn't show some graphical windows Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: idarktemplar(a)mail.ru Distribution: --- Created attachment 73990 --> https://bugs.winehq.org/attachment.cgi?id=73990 SteamSetup.png When I'm building wine with new experimental wow64 mode, it is unable to properly show or render application windows for some applications. I've tried it both on clean prefix and on existing prefix. I've tried Steam setup and Battle.net setup, both failed. With Battle.net setup I see no window, with Steam setup I see black window with some artifacts. When using multilib wine built old way, everything works as usual. Happens both with wine 8.0 and 8.1. OS: Gentoo Linux amd64 (64bit) Graphics: X11 Videocard information: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro K1000M/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 470.161.03 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile Wine build options: ./configure --with-mingw --enable-archs='i386,x86_64' --prefix=/tmp/wineinstall Default wine output: $ WINEPREFIX=/tmp/wineprefix/prefix1 /tmp/wineinstall/bin/wine /tmp/SteamSetup.exe 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0090:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 0034:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 010c:err:environ:init_peb starting L"Z:\\tmp\\SteamSetup.exe" in experimental wow64 mode 010c:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 010c:fixme:imm:ImeSetActiveContext (00020046, 1): stub 010c:fixme:imm:ImmReleaseContext (00010052, 00020046): stub 0090:fixme:imm:ImeSetActiveContext (0000000000010026, 0): stub 0090:fixme:imm:ImmReleaseContext (0000000000010020, 0000000000010026): stub -- 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.

1 9

[Bug 54848] New: dnsapi:query - test_DnsQuery() fails on Rémi's Wine test machines
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=54848 Bug ID: 54848 Summary: dnsapi:query - test_DnsQuery() fails on Rémi's Wine test machines Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dnsapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- dnsapi:query - test_DnsQuery() fails on Rémi's Wine test machines: query.c:66: Test failed: expected record name L"winehq.org", got L"." query.c:67: Test failed: expected record type 1, got 41 query.c:96: Test failed: unexpected CNAME chain See https://test.winehq.org/data/patterns.html#dnsapi:query test_DnsQuery() also has failures on the TestBot's VMs (see bug 54847) but the failures on Rémi's machines are different and not easily explained by the CDN used by winehq.org. They may instead be caused by the cloud environment these machines are running on. These failures happen in new tests that were introduced by this commit: commit 6e2efe54f17e72415b790edf6c9c1f9de5acb9f7 Author: François Gouget <fgouget(a)codeweavers.com> Date: Thu Apr 13 05:51:20 2023 +0200 dnsapi/tests: Test how DnsQuery() handles CNAMEs. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54819 -- 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.

1 9

[Bug 54797] New: Lunar Magic 3.33: Crashes with BadWindow unless WINEDEBUG=+all
by WineHQ Bugzilla June 23, 2023

June 23, 2023

https://bugs.winehq.org/show_bug.cgi?id=54797 Bug ID: 54797 Summary: Lunar Magic 3.33: Crashes with BadWindow unless WINEDEBUG=+all Product: Wine Version: 8.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xhsdf.misc(a)googlemail.com Distribution: --- Created attachment 74294 --> https://bugs.winehq.org/attachment.cgi?id=74294 warn+all output Starting with Wine 8.4 Lunar Magic crashes on startup with X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 12 (X_ConfigureWindow) Resource id in failed request: 0x60001e8 Serial number of failed request: 600 Current serial number in output stream: 601 It works when WINEDEBUG=+all or trace+all is used, but then it runs very, very slowly. Lunar Magic can be found here: https://fusoya.eludevisibility.org/lm/program.html I'm using up-to-date Archlinux on a Ryzen 7 5700X and Radeon RX 6650 XT running Openbox. -- 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.

1 3