Emulator

sammi-husky wrote:

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?

Tested on 5.0-2684 and 5.0-532. The last version to work was Dolphin 4.0-9247

Whoops, i meant the last version to work should be Dolphin 4.0-9240

JMC4789 wrote:

Maybe phire can explain. Do you know what you actually wanted the title to be? I can fix that.

Ah, yes thank you. I was going to title it "Breakpoints crash game after stepping" or something of the like.

Can I know a particular function/address in the game you know a breakpoint there would cause this issue?

I am trying to reproduce it and to do that, I need to know a place where hitting the breakpoint is a problem. I ask this because if I try to breakpoint shortly after boot, I don't encounter this issue, but this might be because not much is going right after boot.

aldelaro5 wrote:

Can I know a particular function/address in the game you know a breakpoint there would cause this issue?

I am trying to reproduce it and to do that, I need to know a place where hitting the breakpoint is a problem. I ask this because if I try to breakpoint shortly after boot, I don't encounter this issue, but this might be because not much is going right after boot.

Easiest one to do would probably be placing a breakpoint at 0x810c7c4c before selecting Mario in training mode. Soon as he's selected the breakpoint will be hit.

I can't reproduce the crash with Dolphin 5.0-3303. The breakpoint (0x810c7c4c) in training mode is hit when I selected Mario but I didn't have a crash.

PC value is set to 0x500 when an External Interrupt Exception is raised, so that's normal. Furthermore, after stepping out (after hitting the rfi instruction) the PC will be set to 0x801dd644 which is the ExternalInterruptHandler you're looking for. However, I assume the game didn't like it because I was sent to PPCHalt later on. No crashes, but an infinite loop that prevent me to do anything else instead.

Not to mention, the breakpoint won't be hit twice once Mario has been selected (it seems?). I was able to raise that exception but that was quite situational and the other times it didn't happen. I can't reproduce it if I do a save state before triggering the bug. Sometimes, I'd to select Mario twice in order to trigger the breakpoint so it seemed that the module wasn't loaded completely at that time (since the PPC code was different). It tends to happen more often to me right at the begin but not after idling and doing random stuff on the character roster for a while before selecting Mario.

I highly suspect this issue to impact other games, like MH3 where I've similar troubles and get sent to PPCHalt after a breakpoint hit. I'll detail what I've learnt so far concerning brawl case, though.

The exception is set in the PPC state during CoreTiming::Advance() call. Furthermore, that happens during an event callback, more specifically: evt.type->callback(evt.userdata, g_global_timer - evt.time);, the evt.type name is "SetTokenFinish". The function called is SetTokenFinish_OnMainThread(0, cycles_late) where userdata is zero and cycles_late is a small value. It changes each time but still stay small (I've seen it between 0x00000000000006d1 and 0x0000000000002af5, so far). Delaying the breakpoint by placing it further down doesn't fix the issue and the exception is still triggered. The code changing the PPC state is the following: ProcessorInterface::SetInterrupt(INT_CAUSE_PE_TOKEN, s_signal_token_interrupt && m_Control.PETokenEnable);.

When the issue isn't triggered, for instance while using a savestate for me, there are no events to process, so there is no callback and no exceptions are set in the PPC state.

However, when the issue happens, the game processes that exception and later on enters in the Relocate function. The thing is, when it exits the function the PC is set to zero. That raises another exception that leads to the PPCHalt function but just before that prints a bunch of debug messages via OSReport such as Attempted to fetch instruction from invalid address 0x0 (read from SRR0).

@sammi-husky
Does the PR #5274 fix the issue?

sepalani wrote:

@sammi-husky
Does the PR #5274 fix the issue?

Right, this problem was initially present in both Vanilla brawl and games run through Gecko OS or anything using it's codehandler, but this PR does fix it in vBrawl.

Games run through Gecko still seem to crash instantly when stepping after a breakpoint however, where they didn't back in 4.0-9240