Fix SMS/GG debugger step-back non-determinism bug#16
Open
CharlesVanEeckhout wants to merge 1 commit intonesdev-org:masterfrom
Open
Fix SMS/GG debugger step-back non-determinism bug#16CharlesVanEeckhout wants to merge 1 commit intonesdev-org:masterfrom
CharlesVanEeckhout wants to merge 1 commit intonesdev-org:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
i had originally found this bug on mesen 2.1.1 on 2025-10-20
heres what i had written back then on the snesdev discord:
i have found a non-determinism bug with the step-back function of the mesen debugger
i have coded a homebrew rom to isolate and demonstrate this bug
stepback.gg.zip
steps to reproduce:
1. place breakpoint at game gear memory 0x00B2 (instruction should be ld b, a)
2. continue execution until the breakpoint. notice that A register is $55
3. continue execution past the breakpoint. this $55 is used to make the background dark gray.
4. reset the rom and run rom until the breakpoint
5. this time, use the step-back function (shift+f10) until pc is 0x00a9 (this should be the first of eight nop)
6. continue execution until the breakpoint again. notice that A register is now $AA
7. continue execution past the breakpoint. this $AA is used to make the background light gray.
this is a bug because the value of A register at step 2 and the value of A register at step 6 should be the same value
root cause for the bug:
in Core/SMS/SmsVdp.cpp, some calls to
SmsVdp::ProcessVramAccessonly occur when_memAccess[cyc] == SmsVdpMemAccess::Nonegoing forward normally, the
_memAccess[cyc]would beSmsVdpMemAccess::None, and then insideSmsVdp::ProcessVramAccess, it would be set toSmsVdpMemAccess::CpuSlot, and would eventually get cleared when the scanline endsbut if instead of letting the scanline end, i step-back to before the
SmsVdp::ProcessVramAccesscall, since_memAccessis not serialized,_memAccess[cyc]remainsSmsVdpMemAccess::CpuSlotinstead of returning toSmsVdpMemAccess::Noneas would be expectedthis makes the call to
SmsVdp::ProcessVramAccessfail to occur as it had the first time around, because_memAccess[cyc] == SmsVdpMemAccess::Noneis no longer truebecause the vram access now fails to occur, stale values remain in the
_state.VramBufferfor longer than they should (this is the $AA in my example)my solution:
i serialized the
_memAccessarraythis way, stepping-back restores the previous values of
_memAccesscorrectly, thus allowing allSmsVdp::ProcessVramAccesscalls that depend on_memAccessto remain consistent, whether or not step-back is used