Correction to my own filing: I wrote that this could be folded into #9164,
but on closer reading #9164 is an "Out of video memory" crash at launch with
a D3D12RHI stack trace — a different failure from this one, which happens
20-40 minutes into a session with a SIGSEGV in ntdll.so setup_raise_exception.
The closer match is #9827 (sigsys_handler advancing %rip by +0xb on raw
syscall instructions emitted by Denuvo Anti-Cheat), which lists SIGSEGV as one
of its failure modes. That issue was closed as a duplicate of #9164, but those
two also describe different problems — so that mechanism may not currently be
tracked by any open issue.
Hello @dec0y1, we're using one issue report per unofficially supported game title, and usually I'd transfer this issue report to #9164, but for some reason you've decided to use AI tools to greatly degrade what you're trying to communicate. Please add a note to that issue report with what you're experiencing, using your own words instead of whatever tool generated this, and include a Proton log for a Proton dev to ponder.
proton experimentalx1 2026-09proton hotfixx1 2026-09PROTON_NO_ESYNC=1x1 2026-09PROTON_NO_FSYNC=1x1 2026-09
Compatibility Report
System Information
I confirm:
Symptoms
The game appears to freeze mid-match for 15-30 seconds and then disappears.
It is not a hang —
systemd-coredumprecords a SIGSEGV at the exactinstant the picture freezes; the visible "freeze" is post-crash teardown. No
Unreal crash report is produced because the process dies inside
wine-preloaderbefore Unreal's handler completes.16 crashes between 2026-09-12 and 2026-09-30, roughly every 20-40 minutes
of play. No gameplay trigger — the most recent occurred while running through
an empty part of the map with no combat and no other players nearby.
Always the same crash site, on two different Proton builds. Resolved with
gdb against each build's own
ntdll.so:Both crash inside
setup_raise_exceptionwith a stack pointer pointing atunmapped memory, so the stack cannot be walked:
This looks like a double fault: something faults first, and Wine then crashes
building the exception frame to deliver it, masking the original fault.
Across six Experimental dumps the crash address had identical low bits (
b2d)under six different ASLR bases — one reproducible code path, not random memory
corruption.
Post-crash behaviour differs between builds (2 s samples):
In both cases ~200 other threads are idle and the GPU falls to 0-5%.
Ruled out with measurement:
wineserveruses 0 ms CPU during theevent.
PROTON_NO_ESYNC=1+PROTON_NO_FSYNC=1ran for ~8 days with noeffect and have been removed.
faults in the entire journal.
vm.max_map_count— already 1048576, not the distro default.both builds, no
ARAV1011kick.Reproduction
Play ARC Raiders for 20-40 minutes. No specific action required.
arc-trace-20260930-112959-tail.csv
arc-trace-20260930-121102-tail.csv
crash-timeline.txt
system-info.txt