ppsspp
ppsspp copied to clipboard
hrydgard
Check thread stack memory overflow
What should happen
it cost me 3 days of debugging to find out that my SDL2 app crashing on a real device vs PPSSPP was because SDL requests only 32KB stacks for threads by default, and my thread was consuming 4x as much. for PPSSPP, it should be trivial to mprotect readonly the 2 pages surrounding the stack memory mapped for sceKernelCreateThread()'s stack, so any access outside the bounds crashes PPSSPP just like it crashes the real PSP. even better would be detection of the OOB access, but i guess that would be harder to implement.
Who would this benefit
anyone developing PSP homebrew and using PPSSPP for quick testing before doing the USB plug dance with the real device.
Platform (if relevant)
Other
Games this would be useful in
Pokemon Yellow
Other emulators or software with a similar feature
No response
Checklist
- [X] Check the latest git build in case it's already implemented.
- [X] Search for other requests of the same feature.
The real PSP does not have per-page memory protection - it doesn't have a concept of pages at all.
In fact, it's unclear to me why the real PSP would crash in this situation and PPSSPP not. I can think of a few explanations:
- Our memory allocation policies are fairly accurate but not 100%, some modules don't take the correct amount of memory in PPSSPP. So, the thread stacks may have been allocated in different positions in memory, with your overwrite bug causing something more critical to be overwritten.
- Maybe the PSP writes a "stack cookie" at the top of the allocated stack, and check and assert on it somewhere? I've never seen any evidence of this, though.
Doing what you suggest would cause a lot of trouble since there's generally not a lot of free space in PSP memory between various allocations like thread stacks.
In fact, it's unclear to me why the real PSP would crash in this situation and PPSSPP not
in fact it didn't crash, but just turned itself off. after setting up psplinkusb, i expected to get a crash address, but that didn't happen - i had to set up psp-gdb too, and here i finally got something - while stepping through my code i got a "SIGHUP", which according to psplink code is an unknown value in a debug register, followed by a SIGBUS.
Maybe the PSP writes a "stack cookie" at the top of the allocated stack, and check and assert on it somewhere? I've never seen any evidence of this, though.
that sounds like a really good idea. i could imagine this to be a cheap way to implement this feature - whenever a task switch to another thread happens, check that thread's stack cookie. it would only cost a dozen cycles vs hundreds needed anyway for the context switch.
Either way, I don't think there's a lot PPSSPP can safely do about this. I suppose we could implement our own stack cookie but I wouldn't be comfortable leaving it on by default. Also, it wouldn't catch everything, you can leave holes when using stack space.
wouldn't be comfortable leaving it on by default.
why not ? you wouldn't have to bring down the process like the PSP does, only print some red warning line in the console as happens for other similar bugs.