It stopped being about memory when CPU_Shutdown started holding it across the
whole teardown - it's what keeps kernel objects, the symbol map and the memory
map from being freed while another thread reads them. The old name invited the
reading that it locks memory *access*, which it has never done.
Memory::Reinit() now holds it across both halves rather than relying on
Memory::Shutdown()'s own acquire: between Shutdown() and Init() there is no
memory map at all, and a reader could slip into that gap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9
The scratchpad (PSP's repurposed-cache scratch RAM, 0x00010000+) was only
mirrored for user-mode access (cached 0x00010000, uncached 0x40010000) -
kernel-mode code sees it at 0x80010000/0xC0010000 (the kernel bit,
0x80000000, is independent of and combinable with the uncached bit,
0x40000000 - not "the uncached bit" as an earlier doc note in this branch
mistakenly called it). Missing entirely from MemMap.cpp's views[] table,
causing a real SIGSEGV the first time kernel-mode code (flash0:/reboot.bin)
touched it.
Adding the two missing views wasn't sufficient: the scratchpad range check
is duplicated eight times (IsValidAddress/IsValid2AlignedAddress/
IsValid4AlignedAddress/MaxSizeAtAddress in MemMap.h, and four more in
MemMapFunctions.cpp), and all eight used a mask (0xBFFFC000) that cleared
the uncached bit but kept the kernel bit, rejecting 0x80010000 as invalid
before ever reaching the now-mapped memory. Fixed all eight to 0x3FFFC000,
matching Memory::MEMVIEW32_MASK (which the JIT backends already used
correctly for the equivalent runtime check).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9
Need to make sure a buffer size check happens before the buffer is
accessed - since the game calls sceAtracSetDataAndGetID with both buffer
and bufferSize as 0, and it expects to receive TOO_SMALL and not a
memory exception.
Thanks to @sum2012 for quick investigationh help.
We don't have it mapped in our memory map, so this can actually crash
checked reads like Read_U32.
Since it isn't mapped, and it can't possibly be valid in retail PSP
games to access VRAM this way, I don't think this will cause any
problems.
However, if it does, we'll have to add the corresponding mappings to the
memory map.
Potentially, a watch or break condition could crash if it was unaligned
between mirrors. This might happen if it's not the condition you wanted,
especially. Play it safe.
Probably not worth it for performance reasons, but some semantic cleanup
is good, especially the accidental GetPointer -> writable casts without
using GetPointerWrite.
Using Unchecked on already checked pointers, or when we'd crash anyway
if it returned nullptr, is good for clarity.
* Add range checks in replaced memcpy/memset functions.
Keep seeing especially Replace_memcpy as a semi-rare crash in the
reports. Hopefully this will take care of it, though if games hit this,
they're probably on their way to failing somehow anyway.
* Alternate approach, correctly causing memory exceptions if not ignoring
Henrik Rydgård