http://bugs.winehq.org/show_bug.cgi?id=60281 Victor <victormorel.pro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victormorel.pro@gmail.com --- Comment #2 from Victor <victormorel.pro@gmail.com> --- Independent reproduction on a different application, plus a workaround that seems to support Nilesh's headroom hypothesis in comment 1. Environment ----------- Wine 11.16 (Staging), Homebrew wine@staging cask, 64-bit prefix with the new WoW64. Mac17,2 (Apple M5), macOS 26.5.2 build 25F84, x86-64 under Rosetta 2. The application is a 32-bit Direct3D 9 game from 2013 (PE32, LargeAddressAware), not an installer, so the trigger is not specific to one program. Note the hardware differs from the original report — M5 here, M4 there — which suggests the problem is not tied to one chip generation. Symptom ------- The application fails to start roughly half the time. It dies during Direct3D initialisation, and two thirds of those failures are silent — no application crash report, no macOS diagnostic report. Over 20 preserved attempts: 10 died during D3D init, 3 crashed after reaching the login screen, 7 succeeded. stderr carries the same family of messages as this bug: err:virtual:virtual_setup_exception stack overflow 512 bytes err:virtual:virtual_setup_exception stack overflow 704 bytes err:virtual:virtual_setup_exception stack overflow 1088 bytes err:virtual:virtual_setup_exception nested exception on signal stack err:seh:call_seh_handlers invalid frame 000000000022B8C0 (0000000100112000-000000010020FD20) err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception We do not see the RtlUnwindEx loop described here; our runs fail at frame validation instead. It may be the same root cause surfacing differently, or a neighbouring one — we cannot tell. Two observations that may help ------------------------------ 1. Raising the Unix stack limit measurably reduces the failure rate. Launching Wine through sh -c 'ulimit -s 65520; exec wine ...' instead of inheriting macOS's default 8 MB removes most of the stack overflow messages and improves the launch rate. Measured on cold starts, same prefix, same binary, alternating conditions: default stack limit 17 attempts for 5 launches 64 MB stack limit 7 attempts for 5 launches That a larger *host* stack helps, when the overflowing amounts are only a few hundred bytes, fits comment 1: the failure is not that the application needs more stack, it is that the exception path has no headroom left to run. Raising the limit does not fix the cause, it makes the recovery path survivable. 2. The reported fault address does not match the reported instruction. Our application writes a minidump. It records C0000005 at 7BF21239 with a faulting read address of 0x00002dc1. With WINEDEBUG=+loaddll, 7BF21239 falls inside wow64cpu.dll (loaded at 7BF20000), in the function that ends where BTCpuSimulate begins — the syscall entry thunk, just after xchgq %r14, %rsp. The instruction at that offset is a RIP-relative load: 7BF21239: movl 0x2dc1(%rip), %edx Executed at 0x7bf21239, its effective address should be around 0x7bf24000, not 0x2dc1 — which is the instruction's own displacement field. The exception record's memory address is therefore inconsistent with the effective address implied by the reported instruction pointer and instruction bytes, suggesting the state propagated through the WoW64 exception path does not faithfully describe the 64-bit thunk. Similarly, in call_seh_handlers above, 0x0022B8C0 looks like a 32-bit guest stack address while 0x100112000–0x10020FD20 is plainly a 64-bit range: a guest frame appears to be validated against host stack bounds. Ruled out on our side --------------------- Measured with alternating conditions, three launches per series, because the failure rate is widely dispersed (the unmodified configuration ranged from 3 to 12 attempts per three launches): raising the PE header stack reserve to 8 MB, restricting the process to efficiency cores, WINEPRELOADRESERVE, dbghelp=disabled, DXVK for D3D9, clearing the application's shader cache, windowed instead of fullscreen, and verbose WINEDEBUG channels. One more thing that helps, for whatever it is worth: running a trivial 32-bit cmd.exe before the application more than halves the failure rate on a cold prefix. That points at per-process or per-thread WoW64 setup rather than at anything the application does. We can attach the minidump, the module map and full stderr if useful. We cannot provide a reproducible test case — the application is a private server client — but nothing about it looks special: it is an ordinary 2013 Direct3D 9 title that raises a lot of exceptions during initialisation. -- 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.