Strangely, I can't reproduce this issue anymore. It seems that the problem has been fixed by one of the updates in the bleeding-edge branch. I'll close this until I can reproduce this issue again.
I can reproduce something "similar", with Lutris.
I only had one crash though and it crashed chmod for some reason.
Here's GDB log:
Core was generated by `chmod +x /extend2/Lutris/PlantFactory/dosdevices/c:/proton_shortcuts/Uninstall'.
Program terminated with signal SIGSYS, Bad system call.
#0 0x00006fff2c72f0cb in ?? ()
(gdb) bt
#0 0x00006fff2c72f0cb in ?? ()
#1 0x00006fff2c729738 in ?? ()
#2 0x00005e075dea5040 in ?? ()
#3 0x000000000000000d in ?? ()
#4 0x00005e075dea7bb0 in ?? ()
#5 0x0000000000000000 in ?? ()
@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.
proton 11.0x1 2026-08proton experimentalx1 2026-08PROTON_LOG=1`.x1 2024-070xc000003ex1 2026-08
Compatibility Report
As far as I can remember, this problem happens with different games. The last time I encountered this problem was at
SCP: Secret Laboratory (700330).System Information
Radeon RX 7600Mesa 24.2.0-devel (git-e506955056)6.9.9-zen1-1-zen1720827808 experimental-bleeding-edge-9.0-107384-20240712-pce1e86-wcf089d-da8dbbc-vebe727-unstrippedI confirm:
Symptoms
In this case, after the pop-up window from Steam about the launch of the game disappears, the game will not start. When using
coredumpctl, it can be observed that a memory dump has occurred in thewine64-preloaderprocess due toSIGSYS.Reproduction
To reproduce this problem, it is enough to launch the game in the usual way. This problem is random and usually occurs once every few days. Today I downloaded the version of Proton with debug symbols, and as soon as this problem occurs again, I will try to attach a backtrace file from
gdband a log from Proton with an environment variablePROTON_LOG=1.