starred/shadPS4

Fork 0

mirror of https://github.com/shadps4-emu/shadPS4.git synced 2026-04-26 08:15:59 +03:00

[GH-ISSUE #460] Access violation from game calling libc.prx::memcpy() [CUSA02480] #87

New issue

Closed

opened 2026-02-27 21:04:29 +03:00 by kerem · 8 comments

kerem commented

2026-02-27 21:04:29 +03:00

Owner

Originally created by @xezrunner on GitHub (Aug 17, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/460

When booting Amplitude CUSA02480 (after temporarily patching currently missing Srgb image format support*), what looks to be the game code encounters an access violation when attempting to write to a valid memory address.

*I doubt this is responsible for the crash, as the temporary patch simply interprets the Srgb data as if it were Rgb8, which the project does support. This has made the ESRB logo appear on startup before, until some commits caused this change in the boot process.

Could this be a memory mapping issue, such as wrongly marking some memory region as inaccessible for writing?

Both memory locations that the game assembly references (rdi and rsi) are valid memory addresses that can be viewed in the Memory window of Visual Studio.

I believe the game was able to perform this operation before on earlier builds of shadPS4, as the game was crashing way later into the boot process with some shader-related errors. I was able to see an ESRB rating splash, now it's crashing before that.

Originally created by @xezrunner on GitHub (Aug 17, 2024). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/460 When booting Amplitude `CUSA02480` (after temporarily patching currently missing Srgb image format support\*), what looks to be the game code encounters an access violation when attempting to write to a valid memory address. \*_I doubt this is responsible for the crash, as the temporary patch simply interprets the Srgb data as if it were Rgb8, which the project does support. This has made the ESRB logo appear on startup before, until some commits caused this change in the boot process._ Could this be a memory mapping issue, such as wrongly marking some memory region as inaccessible for writing? Both memory locations that the game assembly references (`rdi` and `rsi`) are valid memory addresses that can be viewed in the Memory window of Visual Studio. I believe the game was able to perform this operation before on earlier builds of shadPS4, as the game was crashing way later into the boot process with some shader-related errors. I was able to see an ESRB rating splash, now it's crashing before that. ![image](https://github.com/user-attachments/assets/759a14ec-1ae2-4a01-820d-6c7af4f07e97)

kerem closed this issue

2026-02-27 21:04:29 +03:00

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 18, 2024):

Nothing seems out of the ordinary in the logs - that sceNetCtlGetState() stub call happens numerous times before the crash.

@xezrunner commented on GitHub (Aug 18, 2024): Nothing seems out of the ordinary in the logs - that `sceNetCtlGetState()` stub call happens numerous times before the crash. ![image](https://github.com/user-attachments/assets/4329ff49-5c52-449a-b6fc-026dc62bf1e0)

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@lzardy commented on GitHub (Aug 18, 2024):

In stubbed cases, the game may assume certain things have been filled with data, as our stubs emit OK, or successful operation.
As such, games will try accessing the presumed data, and fail.

@lzardy commented on GitHub (Aug 18, 2024): In stubbed cases, the game may assume certain things have been filled with data, as our stubs emit `OK`, or successful operation. As such, games will try accessing the presumed data, and fail.

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 18, 2024):

That makes sense. Perhaps some stubs could have changed since the game last booted past this point.

I assumed the two registers holding seemingly coherent memory addresses would mean this isn't a game-related problem, but it does make sense that those areas in memory could be invalid, having not been initialized/mapped yet, due to the stubs.

I'll see if I can figure out what the game is trying to do at this point and pinpoint the stubbed function, if that's indeed what it is. Thanks for pointing me in a direction!

@xezrunner commented on GitHub (Aug 18, 2024): That makes sense. Perhaps some stubs could have changed since the game last booted past this point. I assumed the two registers holding seemingly coherent memory addresses would mean this isn't a game-related problem, but it does make sense that those areas in memory could be invalid, having not been initialized/mapped yet, due to the stubs. I'll see if I can figure out what the game is trying to do at this point and pinpoint the stubbed function, if that's indeed what it is. Thanks for pointing me in a direction!

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 19, 2024):

I managed to figure out further information by finding the same piece of code that the disassembly in VS shows.

This issue is not related to stubs, that just happens to be the last log entry the game provides.

The crash is happening within memcpy().

More specifically, the game seems to be calling libc.prx::memcpy:

The disassembly shown in the final stack frame seems to be coming from the library, as this piece of code does not exist within the game nor the sys_modules libs supplied with the game:

Aren't such calls supposed to be redirected to/handled by the emulator? It seems as though the game is directly using the PS4-supplied libc instead.

I noticed that the emulator does have functions for libc stuff, so I assume the intention is for games to use them?

@xezrunner commented on GitHub (Aug 19, 2024): I managed to figure out further information by finding the same piece of code that the disassembly in VS shows. This issue is not related to stubs, that just happens to be the last log entry the game provides. The crash is happening within `memcpy()`. ![image](https://github.com/user-attachments/assets/c8b2d8d9-1da7-4339-9105-2dc5f1123647) More specifically, the game seems to be calling `libc.prx::memcpy`: ![image](https://github.com/user-attachments/assets/dfe3e3a6-49a3-40c5-ad69-b2e28e11c971) The disassembly shown in the final stack frame seems to be coming from the library, as this piece of code does not exist within the game nor the `sys_modules` libs supplied with the game: ![image](https://github.com/user-attachments/assets/ee8de574-572e-4c80-afef-37f028bfb5ea) Aren't such calls supposed to be redirected to/handled by the emulator? It seems as though the game is directly using the PS4-supplied `libc` instead. I noticed that the emulator does have functions for `libc` stuff, so I assume the intention is for games to use them? ![image](https://github.com/user-attachments/assets/31306223-fed2-495f-81ec-c254192982b8)

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@polybiusproxy commented on GitHub (Aug 19, 2024):

Yes, that's indeed the intended use case. However, I believe libc.prx is LLE'd.
Can you share a log? Also, if you're on the Discord server, feel free to ping me so we can discuss things further in there.

@polybiusproxy commented on GitHub (Aug 19, 2024): Yes, that's indeed the intended use case. However, I believe libc.prx is LLE'd. Can you share a log? Also, if you're on the Discord server, feel free to ping me so we can discuss things further in there.

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 19, 2024):

Here's a log:

shad_log.txt

@xezrunner commented on GitHub (Aug 19, 2024): Here's a log: [shad_log.txt](https://github.com/user-attachments/files/16664054/shad_log.txt)

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 19, 2024):

After having read through the log, I realized that there is indeed a libc.prx in the sys_module directory. I overlooked it twice, despite having it loaded into Ghidra. Apologies!

If I make it inaccessible to the game, it is now using the emulator-supplied calls under Libraries::LibC instead.
It still crashes, but no longer in unknown code.

Is it intended for the emulator to use the game-supplied libs, including PS4-specific libraries such as libc?

@xezrunner commented on GitHub (Aug 19, 2024): After having read through the log, I realized that there is indeed a `libc.prx` in the `sys_module` directory. I overlooked it twice, despite having it loaded into Ghidra. Apologies! ![image](https://github.com/user-attachments/assets/9a4c7b98-6f6f-43d4-b55f-c97404900773) If I make it inaccessible to the game, it is now using the emulator-supplied calls under `Libraries::LibC` instead. It still crashes, but no longer in unknown code. Is it intended for the emulator to use the game-supplied libs, including PS4-specific libraries such as `libc`? ![image](https://github.com/user-attachments/assets/d514635e-3e5a-4416-a635-1620d23b80b4)

kerem commented

2026-02-27 21:04:30 +03:00

Author

Owner

@xezrunner commented on GitHub (Aug 19, 2024):

According to developers, this is an intentional debugging feature meant to catch floats and other in-memory game data during development.
I can verify that the copy operations have already happened when the program breaks and the exceptions can be skipped to continue execution as normal.

These exceptions can be excluded from breaking during debugging and should probably be documented.

@xezrunner commented on GitHub (Aug 19, 2024): According to developers, this is an intentional debugging feature meant to catch floats and other in-memory game data during development. I can verify that the copy operations have already happened when the program breaks and the exceptions can be skipped to continue execution as normal. These exceptions can be excluded from breaking during debugging and should probably be documented.

kerem referenced this issue

2026-02-27 21:11:54 +03:00

[PR #87] [MERGED] submodules fixes #1278