October 2022 - Wine-Bugs - list.winehq.org

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #13 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- > The attached patch, with the separate "DECLSPEC_NORETURN __attribute__((noinline)) call_user_mode_callback", there's a much greater chance of this still holding up (with a noreturn function, there's little point for the compiler to store anything else on the stack. No it's stronger than that. It's noinline that's controlling the compiler, noreturn is just descriptive. In that patch, the setjmp(&jmpbuf) is in KeUserModeCallback. But the callback_frame is in call_user_exception_dispatcher, which, always gets its *own* stack frame (because of noinline). We still smash up the stack of call_user_exception_dispatcher, just like it used to for KeUserModeCallback. But since the longjmp points to KeUserModeCallback, the epilogue of call_user_exception_dispatcher will never get a chance to care. > When setting up a new syscall_frame on the current stack, and calling __wine_syscall_dispatcher_return, we'd need to make sure that the new syscall_frame is at the very exact bottom of the stack. Yes (given the current __wine_syscall_dispatcher_return). zf and I weren't sure whether that is just convenience, or if there was an actual reason why the stack and syscall_frame needed to be contiguous. If you think it's OK to just add an arbitrary gap, then it would seem more robust for asm code in __wine_syscall_dispatcher_return to simply preserve its own $sp value (which was properly set up by its caller), rather than overwriting it with $sp = syscall_frame. Then it's just going to naturally be the correct stack, rather than an arbitrary 0x100 offset. (maybe this would mean we need a __wine_syscall_dispatcher_return_callback that differs from __wine_syscall_dispatcher_return, if the usage in handle_syscall_fault and call_init_thunk need to do this). > MSVC could leave a gap at the bottom of the stack Yeah, and on x86_64 MSVC will *always* leave a gap at the bottom, beacuse that's just part of the ABI: https://learn.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170#stack… > The parameter area is always at the bottom of the stack (even if alloca is used), so that it will always be adjacent to the return address during any function call. It contains at least four entries, but always enough space to hold all the parameters needed by any function that may be called. Note that space is always allocated for the register parameters, even if the parameters themselves are never homed to the stack; a callee is guaranteed that space has been allocated for all its parameters -- 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.

Oct. 21, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #12 from Martin Storsjö <martin(a)martin.st> --- Created attachment 73348 --> https://bugs.winehq.org/attachment.cgi?id=73348 Patch adding a stack gap in __wine_syscall_dispatcher -- 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.

Oct. 21, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #11 from Martin Storsjö <martin(a)martin.st> --- Thanks for the pointers! As discussed on irc, now I was able to reproduce it - it didn't reproduce when building the ELF code with Clang, and it didn't reproduce with Ubuntu 20.04's GCC 9.4.0, but it did reproduce with Ubuntu 22.04's GCC 11, and with vanilla GCC 9.2 built on Ubuntu 20.04. I think I understand the issue now. So basically, __wine_syscall_dispatcher assumes that syscall_frame is at the very bottom of the syscall stack. When setting up a new syscall_frame on the current stack, and calling __wine_syscall_dispatcher_return, we'd need to make sure that the new syscall_frame is at the very exact bottom of the stack. With local variables in C, there is effectively no such guarantee - the compiler is free to do whatever stack layout it wants to. The attached patch, with the separate "DECLSPEC_NORETURN __attribute__((noinline)) call_user_mode_callback", there's a much greater chance of this still holding up (with a noreturn function, there's little point for the compiler to store anything else on the stack. But the compiler still could. (E.g., I recently looked at how MSVC allocates aligned stack objects, and if e.g. syscall_frame would have a larger alignment than the default 16 bytes, MSVC could leave a gap at the bottom of the stack.) So one way of guaranteeing the stack layout, is to use an assembly wrapper. Either that's a lot of assembly, or we'd do a little bit of duplicate work with a small and neat assembly wrapper (setting up a user_callback_frame in a C function, then having the small assembly function just memcpy it to the right stack location and call __wine_syscall_dispatcher_return). There's another small fix that does seem to work for me, but it's not a water tight solution (but it can be made good enough). When __wine_syscall_dispatcher gets its syscall_frame, it then also goes on to call the syscall with the stack pointer set exactly to this value. But we can just as well add a small gap between the previous syscall_frame and the stack pointer we set before handing over to the actual syscall implementation. This would waste a couple bytes of stack, but seems to work for me. -- 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.

Oct. 21, 2022

[Bug 53817] Cookie Clicker crashes with int $3

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53817 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be Summary|Cookie Clicker |Cookie Clicker crashes with | |int $3 --- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Please, update to a recent wine version (>7.10). Also, try wine-staging or run the command "winetricks -q corefonts" (bug 32342). A link to download winetricks can be found there: https://wiki.winehq.org/Winetricks Regards. -- 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.

Oct. 21, 2022

[Bug 47595] Tequila City of Heroes Launcher - expect_no_runtimes Process exited with a Mono runtime loaded.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47595 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Esme Povirk <madewokherd(a)gmail.com> --- Yay, resolving fixed. -- 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.

Oct. 21, 2022

[Bug 53821] New: winbase.h: ReOpenFile declaration missing (and not available in any other header)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53821 Bug ID: 53821 Summary: winbase.h: ReOpenFile declaration missing (and not available in any other header) Product: Wine Version: 7.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: contact(a)ivanchev.net Distribution: --- A declaration for ReOpenFile should be imported with winbase.h (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-reop…) but is currently missing. In fact, no header in Wine declares that function. -- 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.

Oct. 21, 2022

[Bug 53820] New: Trying to install WhatsApp for Windows 32 bits on Manjaro Linux 22

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53820 Bug ID: 53820 Summary: Trying to install WhatsApp for Windows 32 bits on Manjaro Linux 22 Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vinidias(a)protonmail.com Distribution: --- Created attachment 73347 --> https://bugs.winehq.org/attachment.cgi?id=73347 Backtrace output from Wine Hello, folks I tried to install WhatsApp for Windows 32 bits (https://www.whatsapp.com/download) on Manjaro Linux 22 64 bits, Linux Kernel 6.0, Wine 7.19, and gave this on attachment Please, help me to understand and fix this 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.

Oct. 21, 2022

[Bug 53819] New: some versions of Unity engine need GetWindowTheme implemented to properly display crash dialog

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53819 Bug ID: 53819 Summary: some versions of Unity engine need GetWindowTheme implemented to properly display crash dialog Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- So, I've stumbled upon a Unity engine game that crashes every now and then due to what seems to be virtual mapping space exhaustion. Not sure about the crash itself - it's more likely to be graphics related that winegstreamer, but that's just a guess. Anyway, once the crash happens, console is flooded by: 03b0:err:module:DelayLoadFailureHook failed to delay load uxtheme.dll.GetWindowTheme wine: Call from 7B0123C6 to unimplemented function uxtheme.dll.GetWindowTheme, aborting 03b0:err:seh:KiUserCallbackDispatcher ignoring exception and the Unity crash dialog doesn't display properly. -- 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.

Oct. 21, 2022

[Bug 53818] foobar2000 crashes shortly after startup

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53818 matthias.grobarek(a)posteo.de changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73346|application/vnd.tcpdump.pca |application/octet-stream mime type|p | -- 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.

Oct. 21, 2022

[Bug 53818] foobar2000 crashes shortly after startup

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53818 --- Comment #2 from matthias.grobarek(a)posteo.de --- Created attachment 73346 --> https://bugs.winehq.org/attachment.cgi?id=73346 foobar2000 crash dump -- 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.

Oct. 21, 2022