Emulator

Some random thought about that:

"To me, it looks like either of the instructions before/after the corrupted block
operate on the wrong size of operands or something like that..."

Issue 903 has been merged into this issue.

i think if this fix than it will fix most of the game

This also happens for me in the Magmoor Caverns in Metroid Prime 1, in that room with
the single Magmoor and the morph ball rails, just before the elevator to Tallon
Overworld.

Is this happens in the IL version too?

It happens with the IL version too, here's where it crashed :

80a68b84: stwu sp, -0x0008 (sp)
80a68b88: mflr r0
80a68b8c: stw r0, 0x000C (sp)
80a68b90: li r0, 0
80a68b94: ori r0, r0, 0xFFFF
80a68b98: cmpw r4, r0
80a68b9c: bne- ->0x80A68BE4
80a68ba0: cmpwi r3, 0
80a68ba4: beq- ->0x80A68BC4
80a68ba8: JITblock 32969
80a68bac: subi r3, r3, 608
80a68bb0: bl ->0x8012AA94
80a68bb4: JITblock 32969
80a68bb8: subi r3, r3, 580
80a68bbc: bl ->0x8012ACB0
80a68bc0: b ->0x80A68BE4
80a68bc4: JITblock 32937
80a68bc8: lis r11, 0x80A9
80a68bcc: subi r9, r9, 24400
80a68bd0: subi r11, r11, 24472
80a68bd4: lis r10, 0x80C9
80a68bd8: lis r8, 0x80C9
80a68bdc: stw r9, -0x022C (r10)
80a68be0: stw r11, -0x0248 (r8)
80a68be4: lwz r0, 0x000C (sp)
80a68be8: mtlr r0
80a68bec: addi sp, sp, 8
80a68bf0: blr

still those JITblock and those branches :/

Since it affects both JIT, but not the Interpreter, I'd guess that something in
JitCommon might be the problem (from the name, both JIT and JITIL use it, right?)

And as the original poster wrote, I'd say RE4 is a good game to test this bug.
According to him, it always crashes when opening the menu/inventory/whatever for the
second time, hence the first time will perform the JITting and thus break the code.
I dont have RE4, so I can't try it out.

Interpreter_Branch looks a bit easier and shorter to me than the JIT_Branch ones of
both JIT and JITIL. As earlier mentioned, it looks like something in there operates
on the wrong operand size (most probably the bl) and corrupts the memory afterwards.
Hard to say from just looking at the code, not running anything, and (besides) my
limited knowledge of the PPC Instruction set - just my 2ct here.

Yeah Jack, you right ! So it will be possible to fix if you'll get RE4 game ?:)
I think RE4 is the best (or one of the best) game for Dolphin. PC version was badly
ported from PS2 version :( And PS2 version have reduced gfx detail level... So GC
version is original (and BEST !).

btw, i tried to change all the JIT_Branch functions to use the interpreter, and it
crashed too, not at the exact same moment though.
I mean originally it crashes when you open the inventory for the second time, when
using Interpreter_Branch it crashed for the first time i opened it.
So, my guess is that JIT_Branch could be actually fine and that the issue is elsewhere :(

Well, as said, its just a vague idea of where it could be, but since sl1nk3 has
proven me wrong... ;)

Gonna see if I can borrow RE4 somewhere (I'd bet my ass that one of my colleagues got
it), but I'll probably have a hard time dumping it without my Wii.
Besides, I never really liked/cared about RE, so chances of that might still be low :P

Another possible thing would be Wind Waker with the Tower of Gods (where I
experienced the crash a lot of times, pretty much reliably), if I can find my save file.

But since sl1nk3 pointed out that switching to Interpreter also crashes, it might be
a general problem with the PPC instructions (as earlier mentioned, wrong oeprand
size, just with all of the implementations?)
I'll try that out if I can pile up some spare time, painting my room and stuff the
next few days.

err, well completly switching to interpreter works, it won't crash, that's just i
though it was the JIT_Branch but as switching to Interpreter_Branch still crash, it
may not be the branch code (don't know if that's what you said ? o.o)

So err, no idea how to debug this actually, but if you want to give it a try and
reproduce the crash, RE4 is still the easiest one to try, just open the inventory two
times, i don't really know about Wind Waker though :)

Odd, tho it was just a random guess of mine at all.
Wasnt it too much of a coincidence that the bl stays in-place partially (becoming a
b) and corrupting the stuff right after it?
The same for your examples, sl1nk3, the JITblocks occur right after a branch operation.
Btw, do you think you could grab that corrupted snippet of yours and post the initial
state?
Debugging it is one thing, but when you don't have a clue about where it happens, its
pretty much a dead end.

As for Wind Waker, it might be easier than RE4 at all.
Starting a savegame seems to perform the stuff that breaks the function at 8000dff0
as shown in the first post.
Gonna dig around that a bit.

Hm, odd. I used some PanicAlerts to find the places where that location (0x8000e000)
is used, yet the Panics seemed to hit false positives.
Instructions and addresses werent the same as if used in the (positively triggered)
condition, and what-not.

Figured I might switch to SC mode, then this happened:
Heap corruption detected at 0CBBD0F8
Heap corruption detected at 0CBBD0F8
HEAP[DolphinDF.exe]: HEAP: Free Heap block cbbd0f0 modified at cbbd100 after it was freed
Windows has triggered a breakpoint in DolphinDF.exe.

Either way, could anyone point me to the place where the opcodes are stored that are
executed and shown in the debugger? I couldn't seem to pinpoint the location where
that branch gets corrupted.

Did you try to use HLE SOUND Plugin with audio backend = null . I had Zelda WW
crashing in some places until i choose that option for sound

So sound plugin could really be the reason of this problem ?? I would like to help
Jack.Frost, but I'm not a coder :( And I would test Null sound mode, but someone cut
my power supply =(

I'm using HLE with all sounds disabled.
I don't think its sound-related, altho it is as much of a possibility as all the
other plugins are.

Still stuck at the point about finding out where the operations are stored; i'm
planning to put a memory breakpoint on the 0x8000e000 one, and see where it hits.

Hm, interresting, the interpreter mode doesnt seem to fix this either.

1. Run Zelda:WW until the load savegame screen.
2. Pause and switch to interpreter mode, resume.
3. Load the game.
   The memory around 0x8000e000 still gets corrupted...

Seems only to occur when the savegame is after the tower of gods, see attached GCI
for a working (breaking?) savegame.

The code gets overwritten by this guy:
8029b00c stfs f1, 0 (r3)

For some reason, r3 is 0x0000e002. So, boom.

Have fun debugging! :p

This issue occurs with Capcom vs. SNK 2 EO as well. The boss battle in Arcade mode or
a simple matchup in VS or Training mode, anyone of these can't be done twice because
of this crash.

Has progress been made regarding this issue?