Project

General

Profile

Actions

Emulator Issues #10834

closed

Memory breakpoint hit on blr instruction from Mario Party 6 since Dolphin 5.0-2979 only under Windows and JIT

Added by aldelaro5 about 6 years ago. Updated about 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-6333

Description

Game Name?

Mario Party 6

Game ID? (right click the game in the game list, properties, info tab)

GP6E01

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

010dece78287bcb8cafdeb15f035127a

What's the problem? Describe what went wrong.

Under specific circumstances, it is possible to have a memory breakpoint (MBP) get hit while the instruction is a blr which is not a store instruction. The correct behaviour observed on older revision and/or using Linux and/or using the interpreter instead of the jit is the mbp getting hit on a stw instruction.

What steps will reproduce the problem?

0: Start Dolphin 5.0-2979 or later on Windows with debug features (-d argument), make sure the log "MI & Memmap" is checked (you can set it using the log configuration panel).
1: Boot the game.
2: Add the following MBP using the breakpoints panel:

  • Using an address: 805da988, Action: Write, Flags: Log (do NOT use break and log)
  • Using an address: 805E5180, Action: Write, Flags: Break (do NOT use break and log)

3: Select the first file (create one if none), select party mode. When the game prompts which map to pick, select Faire Square, the rest of the settings you can just mash A.
4: Wait until the Sun guy is saying that you are about to hit a dice block to determine the turn order and pay close attention to the log panel (it can help to clear the logs here).
5: Just before the dice block appears (right after pressing A on the last textbox), the game should pause itself, at this point, the last log line should be something like:

56:27:625 PowerPC\BreakPoints.cpp:248 N[MI]: MBP 801871bc (zz_80187194_) Write32 00000006 at 805da988 ( --- )

However, when checking the code panel, 801871bc is actually a blr which cannot have possibly triggered a Write32.

This is the correct log observed from Linux or anything earlier than 5.0-2979 or when using the interpreter:

54:00:549 Core/PowerPC/BreakPoints.cpp:248 N[MI]: MBP 80185428 (zz801852cc) Write32 00000005 at 805da988 ( --- )

NOTE: if the game paue itself between step 2 and 4, ignore them by pressing play.

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, it is present on master and on every version starting from 5.0-2979, this was obtained from a git bisect,

Is the issue present in the latest stable version?

It's a bit weird to test this because mbp hardly works in that version at all.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

Dolphin 5.0-2979

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

This is not a graphical issue.

What are your PC specifications? (CPU, GPU, Operating System, more)
For Linux, intel core i5 4690, Nvidia GeForce GTX 950, Arch Linux
For Windows, I use a Windows 10 vm with KVM/QEMU.

I had someone get this issue on a regular Windows 7 machine with a 4th generation intel Core i5

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

Yes, I performed several debugging tests.

First of all, when checking the memcheck function from MMU.cpp, the PC at the time of the mbp hit is actually the blr one meaning that somehow, the Write32 function got passed the mbp address as argument, but the PC indicate that thsi is impossible.

Second thing to note, I find it extremely weird that this is the version that breaks it simply because all it does is not load all the saved mbp when booting, I even tried to comment out the 2 lines only that loads them and it appears to activate this issue.

Finally, this issue not happening on the interpreter indicate that this would be a JIT related issue which I unfortunately cannot debug further.

Actions #1

Updated by aldelaro5 about 6 years ago

Update, it appears that turning off Fastmem in the INI avoids this issue. I am not sure, but iirc, fastmem is indeed supposed to be disabled when adding the first mbp, that might be the problem.

Actions #2

Updated by JMC4789 about 6 years ago

  • Status changed from New to Accepted
Actions #3

Updated by JMC4789 about 6 years ago

  • Status changed from Accepted to Fix pending
Actions #4

Updated by JosJuice about 6 years ago

  • Status changed from Fix pending to Fixed
  • Fixed in set to 5.0-6333
Actions

Also available in: Atom PDF