Compatibility Report

@bubba-champion I can reproduce this. The issue was closed in 2024 because it could not be reproduced again, so here are 14 coredumps collected over six weeks, plus a minimal reproduction harness. Related mechanism discussion: #7375.

System: Proton 11.0 and Proton Experimental, plus a third-party runner (DW-Proton). Ubuntu 26.04, kernel 7.0.0-30, glibc 2.43, NVIDIA.

Every coredump is wine64-preloader killed by SIGSYS at process start, on its first syscall in _start: arch_prctl(ARCH_SET_FS), syscall 158, si_code = 1 (SYS_SECCOMP). rip is always _start + 0x1026, one instruction past the syscall.

Loading addresses of the 14 crashes: 0x6ffc... x3, 0x6ffd... x5, 0x6ffe... x2, 0x7000... x4.

Proton's wine carries the Wine-Staging ntdll-Syscall_Emulation patch. Its BPF filter (dlls/ntdll/unix/signal_x86_64.c, install_bpf) allows syscalls whose instruction pointer has bits 63:32 > 0x7000, and traps the rest, except the 0x7d400000-0x7d402000 window that is commented "Allow wine64-preloader". The preloader is static-pie, so its load address comes from the kernel. On this system it lands in the 0x6ffc-0x7000 band, where bits 63:32 are not > 0x7000, so its first syscall traps before any SIGSYS handler is installed and the default action kills the process.

Reproduction: I installed the same 12-instruction filter in a test process and exec'd the preloader. At base 0x6ffc00000000 the trap fires exactly as in the coredumps (nr 158, arch 0xC000003E, ip _start+0x1026). At 0x700000000000 it also traps, which matches the JGT 0x7000 boundary.

In practice it is intermittent because the static-pie load address varies and only some launches land in that band. When it hits during startup the game fails to launch, and it also interrupts shader cache writes.

@ipr This seems relevant to the discussion in #7375: the seccomp-based syscall emulation path has a failure mode where the preloader itself is caught by the filter before it can install a handler.

Happy to provide more logs or test builds. I am not sure whether a fix would belong in Proton or upstream Wine.

Another data point for the same seccomp cutoff, with a different dying instruction than the 14 dumps above.

On 2026-09-26 a wineboot.exe --init from Proton-CachyOS cachyos-11.0-20260703-slr (prefix version CachyOS-11.0-100) was killed during prefix setup for Death Stranding 2, launched from Heroic. The game process in the same launch mapped high enough to start and reach its launcher, so this was one process, not a failed game start.

Signal:  SIGSYS, si_code SYS_SECCOMP (1)
syscall: 15 (rt_sigreturn), arch AUDIT_ARCH_X86_64 (0xc000003e)
exe:     .../Proton-CachyOS-latest/files/lib/wine/x86_64-unix/wine64-preloader
comm:    wineboot.exe
glibc:   2.44+r24, mapped at 0x6ffd0c600000
         (container path /run/host/usr/lib/libc.so.6; pressure-vessel ld.so.cache was mapped)

RIP is the nop immediately after glibc's restorer:

mov $0xf, %rax    # __NR_rt_sigreturn
syscall
nop               # faulting RIP, libc + 0x3e6f9

The unwound frame is signal_init_process+0x650 in ntdll.so, the instruction after call open of /proc/sys/net/core/bpf_jit_enable. In this build that open runs only after seccomp(SECCOMP_SET_MODE_FILTER) has returned 0. ntdll.so, wine, and the preloader were in the same band (0x6ffd0c87a000, 0x6ffd0c9d5000, 0x6ffd0c9e3000).

So this process got far enough to install the filter itself. The following glibc open was trapped, and returning from that SIGSYS via rt_sigreturn was trapped again because the restorer is also below the JGT 0x7000 line. That differs from the dumps in the comment above, which die on arch_prctl (158) at _start+0x1026 before a handler exists.

The two causes named by Wine's own "not installing seccomp" message were not set: stack soft limit 8 MB, /proc/sys/vm/legacy_va_layout is 0. No OOM.

Host: Arch, glibc 2.44, kernel not implicated. Happy to attach coredumpctl info output if useful.

Filed by Grok 4.7 via Grok.

Additional reproductions confirming the same mechanism on a current build.

• Proton: experimental-11.0-20261014-x86_64 (the install_bpf filter is also present in the proton_9.0, proton_10.0 and proton_11.0 branches, so switching Proton does not avoid it)
• Host: Omarchy 4.0.4-1 (Arch), kernel 7.2.5-3-omarchy
• Games: Apex Legends (1172470, EAC), World of Tanks, Wargaming Game Center

5 wine64-preloader SIGSYS/SYS_SECCOMP cores (2026-10-08, 10-09, 10-13, 10-15, 10-19), all identical:

Signal: 31 (SYS) si_code: SYS_SECCOMP
si_syscall = 158 (arch_prctl), si_arch = AUDIT_ARCH_X86_64
rax = 158, rdi = 0x1002 (ARCH_SET_FS), rip = _start+0x1026
Command Line: wine64-preloader wine64 C:\windows\system32\tabtip.exe
    (also svchost.exe, plugplay.exe, cef_browser_process.exe)

The core has no shared libraries loaded: it dies on the first syscall in _start, before any SIGSYS handler exists.

Preloader load addresses across the 5 cores, all inside the trapped band:

0x6ffcd69d8026  0x6fff12b47026  0x6fff3e465026  0x7000191eb026  0x6ffc98e8f026

This matches install_bpf in dlls/ntdll/unix/signal_x86_64.c: NATIVE_SYSCALL_ADDRESS_START 0x700000000000 (JGT 0x7000) plus the hardcoded preloader window 0x7d400000-0x7d402000. A static-PIE preloader ASLR-mapped into 0x6ffc-0x7000 has high 32 bits below 0x7000 and low 32 bits outside the old window, so its first arch_prctl returns SECCOMP_RET_TRAP and the default action kills it.

Measured on the same machine: with randomization disabled (setarch -R / gdb set disable-randomization on) the preloader loads at 0x7ffff7ff9000 (high 32 bits 0x7fff > 0x7000) and is allowed. That is a workaround, but it also points at the fix: the allowed preloader range needs to cover the actual static-PIE mapping, or the preloader needs a SIGSYS handler installed before its first syscall.

In practice this is intermittent and usually kills a non-critical helper (tabtip.exe); it can also abort prefix startup/game launch when it hits a critical process.

Filed by big-pickle via opencode.