When CreateFileMapping cannot reserve the guest backing store the log only
carries the raw Win32 error, which gives no clue that the paging file is the
thing to change. Print the size that was asked for and say so directly when the
failure is ERROR_NO_SYSTEM_RESOURCES or ERROR_COMMITMENT_LIMIT.
* kernel: do not release a waiter on a zero-count syncOnAddress wake
sceKernelSyncOnAddressWake with a count of 0 must release no waiters. On
Linux it released exactly one.
WakeLinux passes the count straight to FUTEX_WAKE, which does not treat 0
as "wake nobody": the kernel's wake loop tests `if (++ret >= nr_wake) break`
after waking a waiter, so any waiter present is released before the loop can
break. A standalone futex program confirms it -- FUTEX_WAKE with val = 0
returns 1, and the waiter observes its wait return 0 with the word unchanged.
WakePortable already short-circuits count == 0, so the two backends of the
same ABI disagreed, with only the Linux one wrong.
TestWakeZeroIsNoOp in SyncOnAddressTests covers exactly this and fails on
Linux without the fix (15 consecutive failures on the assertion "zero-count
wake releases no waiters"); with the fix the suite passes 15 consecutive runs.
* kernel: shorten zero-count futex comment
---------
Co-authored-by: nmzik <Nmzik@mail.ru>
Why: Thread-atexit registrations were discarded, leaving objects alive after their guest TLS storage was released.
What: Store registrations per host thread and run them in LIFO order before pthread keys and guest TLS are destroyed.
Why safe: Only callbacks registered on the exiting thread run, once, before existing teardown continues.
* fix: keep hint-less guest mappings at the canonical PS5 base
FindGuestFreeRange searched the low system-managed range first for
mappings with no address hint, so the first hint-less direct-memory map
could land as low as 0x200000. The PS5 kernel never places hint-less
user mappings below 0x200000000 and guest code relies on that: Sony's
libc maps 4 MiB of direct memory for its internal heap, fails its
mspace setup when the returned address is that low, and the first
malloc then dereferences a null mspace (a read at 0x38, the mspace
magic check). On macOS this made Raiden III crash on the main guest
thread a couple of seconds after boot, 100 percent reproducible with
--printf-direction Silent.
Search from the canonical base first, fall back to the user range, and
keep the low system-managed range only as a last resort. The mmap path
already anchored hint-less searches at 0x200000000; this aligns the
shared search helper with it.
Adds two regression tests: the libc-shaped allocation must come back at
or above the canonical base and hold writes, and direct-memory content
must survive an unmap and remap of the same physical range.
* macos: make the fatal-report memory dumps fault-safe
IsReadableRange returned true for any nonzero address on macOS, so the
fatal report's guest memory dumps dereferenced whatever the crashed
thread had in its registers. A fault inside the reporter re-enters the
signal handler and wedges the reporting thread, which hid real guest
crashes whenever logging was enabled: the game kept running with a dead
thread and the report was never completed.
Walk the Mach regions covering the range and require read permission
before dumping, the same contract the Linux implementation provides.
* do not fallthrough HOST_SYSTEM_MANAGED_MIN
---------
Co-authored-by: nmzik <Nmzik@mail.ru>
Augusto Domingos