SWG Legends launcher: deterministic JavaFX crash mid-Update at pc=0xfffffcc8

[nickk02]

Symptom

After clicking Update in the SWG Legends launcher (post-Login), the patcher starts downloading game files, then crashes deterministically. The JVM writes an hs_err_pid*.log and the launcher process exits. Restarting the launcher and clicking Update again hits the same crash at the same address.

Reproduction

1. Fresh bottle via Crosswire's Install Windows App, picking SWGLegendsSetup.exe.
2. Engine: 11.9 from data.grubwire.io (the patched build, all 7 CW HACKs verified present in ntdll.so markers).
3. With dwrite=builtin registry override + _JAVA_OPTIONS=-Dprism.order=j2d -Xint plist applied (i.e., past bugs JavaAppDetector auto-plist seeding skipped: ProgramSettings.decode writes empty default first #91 + the dwrite fix), launcher renders and Login succeeds.
4. Click Update on the post-Login screen.
5. Patcher download begins. SWG dir grows (observed: 219 MB → 392 MB at ~2.8 MB/s).
6. Crash at ~392 MB downloaded. Re-launch and retry → crashes immediately at the same pc=0xfffffcc8.

Crash signature (from hs_err_pid228.log)

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0xfffffcc8, pid=228, tid=0x00000114
#
# JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12)
# Java VM: Java HotSpot(TM) Client VM (25.161-b12 interpreted mode windows-x86 )
# Problematic frame:
# C  0xfffffcc8

Current thread (0x13e82400):  JavaThread "JavaFX Application Thread" [_thread_in_vm, id=276, ...]

siginfo: ExceptionCode=0xc0000005, ExceptionInformation=0x00000008 0xfffffcc8

Registers:
EAX=0x00000000, EBX=0xfffffcc8, ECX=0x00000002, EDX=0x00000002
ESP=0xfffffb74, EBP=0x7bf6f6ff, ESI=0x7bf6f6c7, EDI=0x1485f574

Key details:

• 32-bit JVM (x86), client mode, interpreted mode (due to -Xint)
• Thread is JavaFX Application Thread, state _thread_in_vm (inside JVM C code, not in a Java frame)
• pc=0xfffffcc8 and EBX=0xfffffcc8 — execution jumped to an invalid address near the top of 32-bit space
• ESP=0xfffffb74 — stack pointer also near the top, possible stack underflow
• EBP=0x7bf6f6ff — Wine module base address space (0x7b... range = Wine builtins)
• ExceptionInformation=0x00000008 0xfffffcc8 — Win32 SEH: code 8 = execute violation, address = pc

Hypothesis

pc jumping to a high-address invalid memory region strongly suggests a vtable lookup on a deallocated object — likely a JavaFX scene-graph or Skin object freed by GC while still referenced from a paint callback. The patcher's UI updates (progress bar, file-list scroll) are high-frequency JavaFX paint operations, which would amplify any timing window where a freed object is touched.

Candidates:

1. Wine GDI bug — a GDI handle or DC freed by Wine differently than Windows expects, JavaFX's caching layer holds a stale reference, accesses it on next paint → vtable lookup at uninitialized memory.
2. JIT/interpreter mismatch — but we're running -Xint, so JIT is disabled. Less likely.
3. dwrite=builtin edge case — bug fixed the post-Login CSS-reapply crash but may not cover all DirectWrite call sites the patcher exercises.

CrossOver presumably handles this with their proprietary Wine patches. Real fix likely needs:

• Compare CW Wine source (/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/lib64/wine/) against Gcenx 11.9 for any GDI / dwrite / paint-loop patches we don't have.
• Or build a Wine debug variant of the relevant dlls and run with WINEDEBUG=+seh,+gdi,+dwrite to capture what's being deallocated.

Out of scope (do not chase in the same fix)

• Bug JavaAppDetector auto-plist seeding skipped: ProgramSettings.decode writes empty default first #91 (plist auto-seed not firing) — separate, fixed.
• Bug VERSIONINFO auto-naming did not fire on GUI install flow (SWG bottle 7F4FF523) #92 (VERSIONINFO ordering) — separate, fixed.
• The bare-launcher lib/ extraction issue — separate, zip-aware-install feature.
• The post-login crash documented in SWG Legends launcher: JavaFX crashes on login click in Wine 11.9 (Gcenx) #84 — separate, different stack trace.

Class

Class 2 in the session classification: requires Wine source research, not a quick code change. Likely days of CrossOver-vs-Gcenx diffing or upstream Wine bisection.

Evidence preserved

hs_err_pid228.log in the SWG bottle (now deleted). Crash signature can be re-captured by repeating the reproduction.

Discovered 2026-05-28 during the Checkpoint D end-to-end validation session.