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

[Bug 36211] New: Sybase PowerDesigner 16.5 'pdshell16.exe' (.NET 4.x WPF app) reports scripting error, needs VBScript_AddTypeLib implementation
by wine-bugs＠winehq.org 30 Jun '23

30 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=36211 Bug ID: 36211 Summary: Sybase PowerDesigner 16.5 'pdshell16.exe' (.NET 4.x WPF app) reports scripting error, needs VBScript_AddTypeLib implementation Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, as the summary says ... Prerequisite: 'winetricks -q dotnet40 vb6run' You might need to navigate the main menu items multiple times until the sub-menu popup shows up (another bug). Main menu, select 'File' -> 'New Model' -> 'XML Model' -> 'XML Model Diagram' A message box is shown, telling "scripting error occurred" Unfortunately this isn't reproducible every time. There seem to be multiple Wine bugs in this app, influencing each other :| --- snip --- fixme:vbscript:VBScript_AddTypeLib (0x6cddff8)->() fixme:vbscript:VBScript_AddTypeLib (0x6cddff8)->() fixme:vbscript:VBScript_AddTypeLib (0x6cddff8)->() fixme:vbscript:VBScript_AddTypeLib (0x6cddff8)->() --- snip --- Source: http://source.winehq.org/git/wine.git/blob/9eed654e054520888429fb7ea1c9d8cc… --- snip --- 447 static HRESULT WINAPI VBScript_AddTypeLib(IActiveScript *iface, REFGUID rguidTypeLib, 448 DWORD dwMajor, DWORD dwMinor, DWORD dwFlags) 449 { 450 VBScript *This = impl_from_IActiveScript(iface); 451 FIXME("(%p)->()\n", This); 452 return E_NOTIMPL; 453 } --- snip --- $ sha1sum PowerDesigner165_DMR.exe c74e4cfd99500d9e3e32713b302ea35bc3f911fb PowerDesigner165_DMR.exe $ du -sh PowerDesigner165_DMR.exe 810M PowerDesigner165_DMR.exe $ wine --version wine-1.7.17-148-g2e5cb7a 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.

2 6

[Bug 50938] New: Stop alt key from getting stuck on alt-tab
by WineHQ Bugzilla 28 Jun '23

28 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=50938 Bug ID: 50938 Summary: Stop alt key from getting stuck on alt-tab Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sojuz151(a)gmail.com Distribution: --- When you use alt-tab shortcut to switch to another window and then switch back in, application will at no point receive alt key up signal. User needs to press alt again to make this key unstuck. This behevior is observed in Plasma and in lxde, both of them use alt-tab for windows switching. Behaviour on windows: alt key is not stuck in down position after alt-tabing out of any application How to test: this can be observed in any keyboard testing program. I used switch hitter for testing. Is it really a bug? Maybe not. Still very annoying in full-screen games. -- 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 5

[Bug 49787] New: Java fails to start with "Could not create the Java Virtual Machine" - "Could not reserve enough space for object heap"
by WineHQ Bugzilla 28 Jun '23

28 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=49787 Bug ID: 49787 Summary: Java fails to start with "Could not create the Java Virtual Machine" - "Could not reserve enough space for object heap" Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- You can download java from https://jdk.java.net/java-se-ri/7 (just unpack) To reproduce, just go into "bin" and run "wine java -Xmx1024M -version". -- 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 8

[Bug 49551] New: the installer tries to run Java 2 version 1.3.1 but failed
by WineHQ Bugzilla 28 Jun '23

28 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=49551 Bug ID: 49551 Summary: the installer tries to run Java 2 version 1.3.1 but failed Product: Wine Version: 1.8.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: pritishparihar95(a)gmail.com Distribution: --- Created attachment 67691 --> https://bugs.winehq.org/attachment.cgi?id=67691 Installanywhere windows for reference Installing Software Parashar Light Profession 7.0.1 After InstallAnywhere window no window comes up, I tried to find error code fron winedbg Error code: WineDbg starting on pid 001c 0x7b85f870: subl $8,%esp Invalid address (0x7b85f87a) for breakpoint 0, disabling it Process of pid=001c has terminated -- 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

[Bug 37166] New: Multiple apps fail to detect removable (USB) disk devices (PNP device manager '{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}' device class GUID registry data missing)(TomTom, iTunes, Rufus)
by wine-bugs＠winehq.org 25 Jun '23

25 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=37166 Bug ID: 37166 Summary: Multiple apps fail to detect removable (USB) disk devices (PNP device manager '{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}' device class GUID registry data missing)(TomTom, iTunes, Rufus) Product: Wine Version: 1.7.25 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, continuation of bug 7711 and potentially others to avoid them being recycled over and over again. GUID '{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}' -> GUID_DEVINTERFACE_DISK MSDN: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545824%28v=vs.85… Additionally the apps usually expect GUID '{F18A0E88-C30C-11D0-8815-00A0C906BED8}' class too -> GUID_DEVINTERFACE_USB_HUB http://msdn.microsoft.com/en-us/library/windows/hardware/ff545982%28v=vs.85…: Example trace log with 'Rufus': --- snip --- $ WINEDEBUG=+tid,+seh,+relay,+setupapi wine ./rufus-1.4.10.exe >>log.txt 2>&1 ... 0023:Call setupapi.SetupDiGetClassDevsA(004448fc,00000000,00000000,00000012) ret=0040ef60 0023:trace:setupapi:SetupDiGetClassDevsExW {f18a0e88-c30c-11d0-8815-00a0c906bed8} (null) (nil) 0x00000012 (nil) (null) (nil) 0023:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 00000002 0023:trace:setupapi:SetupDiCreateDeviceInfoListExW {f18a0e88-c30c-11d0-8815-00a0c906bed8} (nil) (null) (nil) ... 0023:Call advapi32.RegOpenKeyExW(80000002,7e2e3bc0 L"System\\CurrentControlSet\\Control\\DeviceClasses",00000000,00020019,0077e944) ret=7e2bf207 0023:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=7e2bf207 0023:trace:setupapi:SETUPDI_EnumerateInterfaces 0x1e2408, {f18a0e88-c30c-11d0-8815-00a0c906bed8}, (null), 00000012 ... 0023:Ret setupapi.SetupDiGetClassDevsA() retval=001e2408 ret=0040ef60 ... 0023:Call setupapi.SetupDiEnumDeviceInfo(001e2408,00000000,0077ec91) ret=0040efd3 0023:trace:setupapi:SetupDiEnumDeviceInfo 0x1e2408 0 0x77ec91 0023:Ret setupapi.SetupDiEnumDeviceInfo() retval=00000000 ret=0040efd3 0023:Call setupapi.SetupDiDestroyDeviceInfoList(001e2408) ret=0040ef91 0023:trace:setupapi:SetupDiDestroyDeviceInfoList 0x1e2408 ... 0023:Ret setupapi.SetupDiDestroyDeviceInfoList() retval=00000001 ret=0040ef91 ... 0023:Call setupapi.CM_Get_Device_ID_List_SizeA(0077ec24,004448b2 "USBSTOR",00000002) ret=0040f260 0023:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0x77ec24 "USBSTOR" 0x00000002: stub 0023:Ret setupapi.CM_Get_Device_ID_List_SizeA() retval=00000000 ret=0040f260 0023:Call setupapi.CM_Get_Device_ID_List_SizeA(0077ec28,004448ba "UASPSTOR",00000002) ret=0040f260 0023:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0x77ec28 "UASPSTOR" 0x00000002: stub 0023:Ret setupapi.CM_Get_Device_ID_List_SizeA() retval=00000000 ret=0040f260 0023:Call setupapi.CM_Get_Device_ID_List_SizeA(0077ec2c,004448c3 "VUSBSTOR",00000002) ret=0040f260 0023:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0x77ec2c "VUSBSTOR" 0x00000002: stub 0023:Ret setupapi.CM_Get_Device_ID_List_SizeA() retval=00000000 ret=0040f260 0023:Call setupapi.CM_Get_Device_ID_List_SizeA(0077ec30,004448cc "ETRONSTOR",00000002) ret=0040f260 0023:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0x77ec30 "ETRONSTOR" 0x00000002: stub 0023:Ret setupapi.CM_Get_Device_ID_List_SizeA() retval=00000000 ret=0040f260 0023:Call setupapi.SetupDiGetClassDevsA(0044490c,00000000,00000000,00000012) ret=0040f350 0023:trace:setupapi:SetupDiGetClassDevsExW {53f56307-b6bf-11d0-94f2-00a0c91efb8b} (null) (nil) 0x00000012 (nil) (null) (nil) 0023:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 00000002 0023:trace:setupapi:SetupDiCreateDeviceInfoListExW {53f56307-b6bf-11d0-94f2-00a0c91efb8b} (nil) (null) (nil) ... 0023:Call advapi32.RegOpenKeyExW(80000002,7e2e3bc0 L"System\\CurrentControlSet\\Control\\DeviceClasses",00000000,00020019,0077e944) ret=7e2bf207 0023:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=7e2bf207 0023:trace:setupapi:SETUPDI_EnumerateInterfaces 0x1e2408, {53f56307-b6bf-11d0-94f2-00a0c91efb8b}, (null), 00000012 ... 0023:Ret setupapi.SetupDiGetClassDevsA() retval=001e2408 ret=0040f350 0023:Call setupapi.SetupDiEnumDeviceInfo(001e2408,00000000,0077ec91) ret=0040f3c2 0023:trace:setupapi:SetupDiEnumDeviceInfo 0x1e2408 0 0x77ec91 0023:Ret setupapi.SetupDiEnumDeviceInfo() retval=00000000 ret=0040f3c2 0023:Call setupapi.SetupDiDestroyDeviceInfoList(001e2408) ret=004103c6 0023:trace:setupapi:SetupDiDestroyDeviceInfoList 0x1e2408 ... 0023:Ret setupapi.SetupDiDestroyDeviceInfoList() retval=00000001 ret=004103c6 ... 0023:Call KERNEL32.OutputDebugStringA(004640d4 "0 devices found\r\n") ret=004164fb ... 0023:Ret KERNEL32.OutputDebugStringA() retval=00000000 ret=004164fb ... --- snip --- $ sha1sum rufus-1.4.10.exe 031309c159429544a4e8bec0373d474c8e705c3e rufus-1.4.10.exe $ du -sh rufus-1.4.10.exe 1.4M rufus-1.4.10.exe $ wine --version wine-1.7.25 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.

2 21

[Bug 41647] New: TFM Music Maker controls are not usable
by wine-bugs＠winehq.org 25 Jun '23

25 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=41647 Bug ID: 41647 Summary: TFM Music Maker controls are not usable Product: Wine Version: 1.9.22 Hardware: x86 URL: http://sega4ever.power-heberg.com/Download/tfmmaker152 .rar OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: notasas(a)gmail.com Distribution: --- After starting the program, click "Instruments" tab and try to adjust any of the knobs. Nothing useful noticed in the terminal output. Just a guess it's an issue message handling, so selected user32 component. Tested to be broken on vanilla wine-1.9.22, wine-1.9.22 (Staging) and wine-1.6.2. Works correctly on real Windows 7 and 8.1. -- 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.

2 5

[Bug 33326] New: Sound problem with Game Maker 8.0 games
by wine-bugs＠winehq.org 25 Jun '23

25 Jun '23

http://bugs.winehq.org/show_bug.cgi?id=33326 Bug #: 33326 Summary: Sound problem with Game Maker 8.0 games Product: Wine Version: 1.5.27 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: georgiev_1994(a)abv.bg Classification: Unclassified When Im starting a game created from Game Maker 8.0 Po it's sound does not start. This is happening with every game Im trying to run. This is caused maybe because of the sound system of Game Maker built games. Here I will give a link just to one game which runs just perfect with Windows OS but not perfect at all with Wine. http://sandbox.yoyogames.com/games/205913/download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 21

[Bug 40119] New: Irfanview 4.x: selection cursor is not correctly aligned
by wine-bugs＠winehq.org 24 Jun '23

24 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=40119 Bug ID: 40119 Summary: Irfanview 4.x: selection cursor is not correctly aligned Product: Wine Version: 1.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Ulf.Zibis(a)gmx.de Distribution: --- - select an area in an image - correct the selection by dragging the left selection border to another position --> the double-ended arrow cursor ofen is not correctly aligned with the selection border I guess this happens, when the image is zoomed. -- 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.

2 9

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

23 Jun '23

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 48811] New: StarCraft II fails to load in staging, crashes after trying to start a game in stable
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=48811 Bug ID: 48811 Summary: StarCraft II fails to load in staging, crashes after trying to start a game in stable Product: Wine Version: 5.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: wschmrdr(a)gmail.com Distribution: --- Created attachment 66725 --> https://bugs.winehq.org/attachment.cgi?id=66725 Output occurring when the application crashes. Ever since upgrading from 5.3 to 5.4, StarCraft II has ceased working. On staging, this occurs during the loading screen. I am able to get through the Battle.net app OK, but cannot get to my login authenticating. I have tried switching to stable, but when trying to load up a game, I see the same output issue. Selected the dbghelp component because that's the line that comes up in the output at the time of the 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.

1 15