Emulator Issues #13367
closed
Access violations on savestate load
0%
Description
Game Name?
Irrespective of game. This occurs for GameCube and Wii games alike.
What's the problem? Describe what went wrong.
On Debug or release builds, Dolphin throws access violations after loading savestates. They are a mix between reads and writes. The number of access violations seems to vary. Access violations usually occur 1 and 2 frames after the savestate load. For Mario Kart Wii I observe around 74 access violations within the 3 frames after a savestate load has occurred. For Paper Mario: TTYD I observe 177 access violations on the frame after loading a savestate.
NOTE: MD5 checksum was verified for these games, so I do not believe this is a gamefile integrity issue.
What steps will reproduce the problem?
- Compile in Visual Studio
- Launch with debugging
- In (Debug -> Windows) Exception Settings, enable Win32 Exceptions -> 0xC0000005 Access violation
- Launch game
- (Save a state and then) Load State
- Observe exceptions thrown for every load state.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes. 5.0-20128
Is the issue present in the latest stable version?
Uncertain. Could not compile past 5.0-11788, where it was also present. Thus I was unable to bisect the origin of this issue.
What are your PC specifications? (CPU, GPU, Operating System, more)
CPU: AMD Ryzen 7 3700X
GPU: AMD Radeon RX 5700XT
OS: Windows 10 Home
RAM: 32GB
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
The access violation is thrown inside constexpr T BitField::Value(std::false_type) const in Source/Core/Common/BitField.h, though I highly doubt execution intended to read this function. Here is one particular callstack I observe, as well as the disassembly:
Files
Updated by JosJuice about 1 year ago
- Status changed from New to Working as intended
If this is happening while the game is running after loading a savestate, as opposed to during the actual loading of the savestate, this looks a lot to me like it's fastmem. And in that case, getting access violations is intended behavior.
As for why you're getting more access violations than normal right after loading a savestate: When one of these access violations is triggered, Dolphin backpatches the offending code to use a slower method of memory access that doesn't cause these faults, meaning that you normally get a bunch of access violations when code firsts executes, but usually not when executing code that already has ran. Loading a savestate clears the JIT's code cache, undoing all the backpatching that happened and leaving the door open for access violations until they get backpatched again.
The bitfield code is a red herring caused by Visual Studio's debugger being confused by what the JIT does to the call stack. To get a proper disassembly of the code that caused the access violation, you need to make sure the first entry of the call stack was selected, which I don't think it was in your screenshot.