Emulator Issues #10117
closed
Adding memory breakpoint while the emulator is runnning can causes it to crash since Dolphin 5.0-2021
0%
Description
Game Name?
Super Mario Sunshine (I however got the same issue in Rogue Squadron 2)
Game ID? (right click the game in the game list, properties, info tab)
GMSE01
MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)
0c6d2edae9fdf40dfc410ff1623e4119
What's the problem? Describe what went wrong.
Since Dolphin 5.0-2021 (https://dolphin-emu.org/download/dev/ef7a809fad6463b5d38c5ebe5270772701af4789/), there's a chance (it depends on the situation) that adding a memory breakpoint while the emulator is running causes it to crash. It never happens before this version and keep in mind that to test this version, I had to apply a hotfix from Dolphin 5.0-2031 (https://dolphin-emu.org/download/dev/5ed94a0f670c15cbb1f097545309692fbba4dfae/). On super Mario sunshine using a 120 shines savefile and adding the memory breakpoint when in Delfino Plaza, it consistently reproduces the issue.
What steps will reproduce the problem?
1 Start Super Mario Sunshine on Dolphin 5.0-2021 or later in debug mode (preferably with a 120 shines savefile, but I don't think it matters)
2 Get to delfino plaza (around 15 minutes of normal gameplay from a new savefile)
3 Add a memory breakpoint (using the breakpoint panel) with the following ooptions:
With an address: 80000000
Action: Write
Flags: Break and Log
4 Upon clicking OK, the game should crash shortly after. This will not happen if the emulator was paused.
Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?
I tested several of them using git bisect and it lead me to this version (after I applied the hotfix to be able to test it)
What are your PC specifications? (CPU, GPU, Operating System, more)
Arch Linux
Intel core i5 4690 3.5 Ghz
Intel HD Graphics 4600 (using Mesa 17)
8Gb RAM
Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
GDB doesn't help and as for why I chose to use 80000000 as address to test, it's because games usually don't read or write to it, but it is alos a valid address for a memory breakpoint.
Updated by aldelaro5 about 7 years ago
After further testing, it appears that this issue can still happen if the emulator is paused and you hit play after so this means that memory breakpoint aren't working properly as a whole since this version
Updated by sepalani about 7 years ago
On Windows Debug Build a vector assertion "vector iterator not dereferencable" is triggered by the GetMemCheck function when getting a reference at the beginning of the for loop. I assume, there might be a race condition somewhere during insertion or deletion of memory breakpoints.
Updated by aldelaro5 about 7 years ago
sepalani wrote:
On Windows Debug Build a vector assertion "vector iterator not dereferencable" is triggered by the GetMemCheck function when getting a reference at the beginning of the for loop. I assume, there might be a race condition somewhere during insertion or deletion of memory breakpoints.
It actually also affects regular breakpoints too. As fgor the race condition, what cxould it be racing? No crashes happens if you remove the clear cache call (of course no memory breakpoints works) so I assume the problem is when clearing th cache.
The problem is I am very confused. I tried to pause and lock, even pause the core before clearing the cache and as soon as it gets running again, it crashes.
How can it race against cleanign the jit cache if it is not actually jitting?
Updated by sepalani about 7 years ago
Can the add/remove bp event be delayed because the emulator is not running or too busy? As far as I'm concerned, that crash only happens to me in the middle of the for loop, not at the beginning. That is to say, something changed the vector meanwhile it was going through the loop.
Updated by aldelaro5 about 7 years ago
I am not sure if it is a race condition anymore.
I did a lot of tests because some results were very weird (it wouldn't crash when it should) and I came to comment these two lines:
https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/MMU.cpp#L787
For some reaosns, that prevented the crash and it seems to be consistent.
Would that make any sense? afaik, this only seems to check if you can use an optimisation, yet for whatever reasons, disabling the return false when there is memchecks is preventing a crash.
The weirdest thing is memcheck actually works if you do this. I have no idea why, is this a workaround or a fix?
Updated by aldelaro5 about 7 years ago
By the way, I don't get the crash int he for loop, I get it outside of the sources file (so jitted code), but I did tried to not use that call in MMU.cpp and it actually did nothing.
Updated by 
Updated by