mirror of
https://github.com/FEX-Emu/FEX.git
synced 2026-10-11 03:00:23 +02:00
Ryan Houdek
ad132267ec
This has been a bug that we have technically lived with ever since SMC tracking was introduced. The problem boils down to the fact that memory management syscalls from multiple threads can race our SMC tracking. This was only uncovered due to recent changes in the Steam client where downloading games has more aggressively started reallocating memory. This causes Steam to oversubscribe the CPU by a small margin, causing threads to context switch more heavily during memory management. The strace that finally managed to capture this: ``` 41574 munmap(0xba84e000, 724992 <unfinished ...> <...> 41227 mmap(NULL, 540672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -3, 0 <unfinished ...> <...> 41574 <... munmap resumed>) = 0 <...> 41227 <... mmap resumed>) = 0xba87b000 ``` While FEX's tracking linearly was: ``` mmap, 0xba87b000, 0x84000, 0x3, 0x22, 0xfffffffd, 0x0 munmap, 0xba84e000, 0xb1000 ``` The way munmap and mmap perfectly interleave while getting context switched meant that the kernel's view of munmap then mmap didn't match our view of mmap completing first then munmap happening afterwards. The kernel/strace is obviously the correct view in this instance. This all comes down to how these threads are racing the VMA tracking mutex after the syscall happens and not guaranteeing sequential consistency that matches the kernel's view. The only way to correct this sanely is to extend the locking period to also encompass the syscalls getting executed. This is a bit tricky since the VMA tracking needs to ensure that the lock is no longer held once ThreadManager invalidation occurs so a callback to do the syscall operation is about the only sane approach here. Luckily we now have fextl::move_only_function. Fixes consistent crashes with Steam game downloads (and maybe some chromium crashes?)