mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-04-26 16:25:58 +03:00
[GH-ISSUE #261] Allocation of virtual memory backing file fails with small page file, crashes program #38
Labels
No labels
Bloodborne
bug
contributor wanted
documentation
enhancement
frontend
good first issue
help wanted
linux
pull-request
question
release
verification progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shadPS4#38
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xezrunner on GitHub (Jul 7, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/261
CreateFileMapping2()returns null after numerous successful attempts at starting a game. Rebooting the system and trying again resolves the issue for a while, but it eventually happens again.I am unsure whether this is an issue on the emulator or Windows side. My machine has 8GB of RAM and a 14GB page file.github.com/shadps4-emu/shadPS4@379ec554a8/src/core/address_space.cpp (L54-L58)I have been attempting to get a game running through debugging, so I have the code up. I inserted my own code to break if the backing pointer is zero:
That assert hits and crashes, even when running the executable without a debugger.
@raphaelthegreat commented on GitHub (Jul 7, 2024):
Call Common::GetLastErrorMsg to get a more detailed description of the error from the OS
@xezrunner commented on GitHub (Jul 7, 2024):
Thanks, that did point me in the right direction!
It is weird how it works initially upon reboot, until some time passes where it just starts returning null.
@xezrunner commented on GitHub (Jul 7, 2024):
I am not familiar with virtual memory management, but I read from Win32 docs:
I manually allocated a larger page file from 4GB to 12GB and that resolved the issue. Noticed that I was sort-of low on disk space, so the OS probably did not allocate a larger page file to conserve space.
Perhaps it would be beneficial to let it map an actual file instead of using the page file in cases where the page file is held small by the OS (so when this "insufficient resources" error occurs)?
@raphaelthegreat commented on GitHub (Jul 7, 2024):
This is not supposed to be a file per sense, its a file mapping so we can map portions of it to the reserved virtual address space. Having it write to disk will not be ideal
@xezrunner commented on GitHub (Jul 7, 2024):
That makes sense. In that case, at least additional logging/non-destructive error handling (useful error message to increase page size?) would be useful here.
This crash seems to be happening early enough that the logging doesn't appear to be initialized yet - the console doesn't show anything and the assertion crashes further when it tries to call
Common::Log::Impl::Stop().@dima-xd commented on GitHub (Jul 14, 2024):
Now I am having the same issue
@Hermiten commented on GitHub (Oct 4, 2024):
Can I have an update on this issue ?Is it still revelant ?
@xezrunner commented on GitHub (Oct 4, 2024):
This appears to have been resolved by making the assert for the allocation also throw an error message from the OS itself in case of failure, which should say
when there isn't enough virtual memory to allocate the backing handle on Windows.
github.com/shadps4-emu/shadPS4@76644a0169/src/core/address_space.cpp (L101-L105)Ideally, a friendlier message could be shown in this particular error case, so that the user would know that they have to increase the virtual memory size, but this varies across platforms.
@Hermiten commented on GitHub (Oct 4, 2024):
Good idea, maybe you can put a PR with this and you will see if it's accepted
Sometimes a good log can be enough for user to understand what to do and improve their tests
@xezrunner commented on GitHub (Oct 4, 2024):
I was considering opening a PR for this, but I'm not sure how platforms other than Win32 are handled. It seems like the whole
address_space.cppfile is only doing Win32 stuff, so it might even be a better idea to consolidate main virtual memory allocations (perhaps there's only one) into a more obvious place for all platforms first and handling the errors there.That would make the scope of the PR larger, which is probably best left to those that are more familiar with the memory allocation-side of things.
@polybiusproxy commented on GitHub (Oct 4, 2024):
address_space.cppincludes implementations for both Win32 and Linux/macOS@xezrunner commented on GitHub (Oct 4, 2024):
I had a look again. I see it now, my bad.
What confused me was that
backing_handleis (seemingly) only assigned to withCreateFileMapping2()in this file, which is a Win32 API call. In fact, that whole part is inside an#ifdef _WIN32.Did not see
backing_handlebeing assigned by anything else, which is what lead me to believe that virtual memory is handled somewhere else for other OSes.I am only looking at it on the surface from GitHub though, and I'm not too familiar with this part of the codebase.
I could probably figure out how a low amount of VM fails on Linux/Mac, but I don't have any of those set up for hacking at the moment.