[Bug 60342] New: Stack overflow exception handling enters infinite re-entry loop and corrupts stack, causing fatal access violation, in Rocksmith 2014 (AppID 221680) on window creation
http://bugs.winehq.org/show_bug.cgi?id=60342 Bug ID: 60342 Summary: Stack overflow exception handling enters infinite re-entry loop and corrupts stack, causing fatal access violation, in Rocksmith 2014 (AppID 221680) on window creation Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: hller@gmx.at Target Milestone: --- Distribution: --- Rocksmith 2014 (Steam AppID 221680): fatal EXCEPTION_ACCESS_VIOLATION after runaway EXCEPTION_STACK_OVERFLOW re-entry loop on second-thread window creation Summary Rocksmith2014.exe (32-bit, PE subsystem 5.01/WinXP) launches, runs briefly, and exits without ever showing a window, on every Wine/Proton build tested (Wine 9.0 through 11.17, two different kernels). With `WINEDEBUG=+seh` enabled, the actual fault sequence is: 1. An initial `EXCEPTION_BREAKPOINT` (0x80000003), immediately followed by a genuine `EXCEPTION_ACCESS_VIOLATION` (0xc0000005) at address `0x93DFC6` (exe loaded at base `0x400000`). 2. Handling of that exception spirals into a **repeated `EXCEPTION_STACK_OVERFLOW` (0xc00000fd) re-entry loop**: the same SEH handler address is invoked over and over (717 dispatch cycles captured in one run), each returning `ExceptionContinueSearch`, with no apparent progress freeing stack space. 3. Each iteration further corrupts the stack, until the value used as the next handler address is plainly garbage (`0x18181010`-style pattern, not a valid code address). 4. Calling that garbage address as a handler produces a final, real `EXCEPTION_ACCESS_VIOLATION` at `0x18181010` — this is the fault that actually kills the process. It is 100% reproducible at the same address/offset on every run with a given Wine build. This looks like Wine's exception dispatch failing to reserve/honor the small amount of guaranteed stack space needed to process a stack-overflow exception on this specific thread (a secondary thread with a 1MB reserve, created right as the game creates its second top-level window), causing infinite re-entry rather than a clean, single stack-overflow report to the application. A near-identical symptom ("stack overflow ... bytes in thread" preventing this exact game from ever showing a window) was previously reported and fixed in Wine 3.19 → 3.21 back in 2018. This appears to be a regression of the same class of bug. Environment - Host: CachyOS (Arch-based), KDE Plasma 6, Wayland/XWayland, i9-13900K, RTX 4090 (proprietary nvidia-utils 615.71.09, tested with both `linux-cachyos-nvidia-open` and its LTS counterpart) - Kernels tested (identical result on both): `7.2.5-1-cachyos`, `6.18.50-3-cachyos-lts` - glibc 2.44 Wine/Proton builds tested — all produce the identical crash signature | Build | Result | |---|---| | proton-cachyos-slr (bundled wine, `cachyos-11.0-20260703`) | crash | | System `wine-staging` 11.17 (fresh prefix, no Proton involved) | crash | | `wine-cachyos-opt` 10.0 (`20260425`, fresh prefix) | crash | | Official Valve Proton 9.0 (Beta) (`proton-9.0-4f`), fresh compat data | crash | Ruled out: - The game's own files: tested with the game's optional CustomsForge D3DX9_42.dll "CDLC enabler", RS_ASIO.dll, and avrt.dll both present and completely absent — no change in behavior. - ntsync on/off (`PROTON_NO_NTSYNC=1` / `PROTON_USE_NTSYNC=0`) — no change. - Wine-Mono and the bundled "xalia" accessibility component disabled entirely (`WINEDLLOVERRIDES=mscoree=d`) — no change (same crash, same address). - Windows version compatibility mode forced to Windows 7 — no change. - Process stack ulimit raised to unlimited — no change (expected, since this is a secondary `CreateThread` stack, not governed by the process's `RLIMIT_STACK`). - Kernel version (7.2.5 vs. 6.18.50 LTS, including the matching nvidia-open kernel module for each) — no change. - `libjack.so.0` visibility (shadowed to an invalid file inside a private bubblewrap mount namespace, without touching the real host file) — no change; confirms no audio/JACK library is even touched at this point in execution. - dmesg is completely clean across all these runs — the kernel never sees an unhandled fault; this is entirely userspace Wine exception-dispatch behavior. Reproduction ```sh WINEPREFIX=~/some-fresh-prefix wineboot -u cd "<Rocksmith 2014 install dir>" WINEDEBUG=-all,+seh,+tid WINEPREFIX=~/some-fresh-prefix wine ./Rocksmith2014.exe -uplay_steam_mode ``` No special configuration needed — reproduces in a completely fresh prefix with only `wineboot -u` run against it, no winetricks, no registry changes. Representative trace excerpt (first fault -> loop -> final crash) ``` 00f4:trace:seh:dispatch_exception code=80000003 (EXCEPTION_BREAKPOINT) flags=0 addr=00000000018673C3 00f4:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=000000000093DFC6 00f4:trace:seh:RtlUnwindEx code=c0000005 flags=2 end_frame=000000010020F620 target_ip=00006FFFFAB2155C 00f4:trace:seh:dispatch_exception code=c00000fd (EXCEPTION_STACK_OVERFLOW) flags=0 addr=000000007BCDE017 ... 00f4:trace:seh:call_seh_handlers calling handler at 7BCE1710 code=c00000fd flags=10 00f4:trace:seh:call_seh_handlers handler at 7BCE1710 returned 2 [... this pair repeats 717 times across the full log ...] 00f4:trace:seh:call_seh_handlers calling handler at 18181010 code=c00000fd flags=10 00f4:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000018181010 ``` Also visible with just `WINEDEBUG=+loaddll,err` (no `+seh`), as the single summary line Wine prints right as the crash becomes fatal, always at the same offset/address for a given Wine build: ``` 0120:fixme:heap:RtlSetHeapInformation HEAP_INFORMATION_CLASS 1 not implemented! 0120:err:virtual:virtual_setup_exception stack overflow 1024 bytes addr 0x18181010 stack 0x130c00 (0x130000-0x131000-0x230000) ``` This always occurs immediately after the process loads `imm32.dll` / `winex11.drv` / `uxtheme.dll` on a newly created secondary thread — i.e. right as the game creates its second top-level window. -- 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=60342 hller@gmx.at changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Other -- 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=60342 --- Comment #1 from hller@gmx.at --- Full trace (37MB) available on request - can't upload here -- 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=60342 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Stack overflow exception |Rocksmith 2014 stack |handling enters infinite |overflow |re-entry loop and corrupts | |stack, causing fatal | |access violation, in | |Rocksmith 2014 (AppID | |221680) on window creation | --- Comment #2 from Ken Sharp <imwellcushtymelike@gmail.com> --- Just upload the normal console output without winedebug flags. Can this be downloaded? -- 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