Emulator

A workaround for this seems to be to reduce the Jit cache size. I think the number below fixed all of the videos except the one at the end, but I can't say for sure.

JitCache.cpp
//MAX_NUM_BLOCKS = 65536*2;
MAX_NUM_BLOCKS = 1024*8*6;

To get the video at the end of the game to work properly I had to reduce the cache size to a ridiculously small value otherwise the game would crash.

I'm not familiar with how the cache works, but it seems that this could be exposing some kind of bug in the cache?

indeed changing the value as you said allows from my testing on the initial cut scene to play flawlessly.

included is the altered jitcache.cpp for the devs too look at. as for the last cutscene i cant say as i am not there yet.

Some infos after a night of debugging (thanks skid_au!):

• Segfault happens when the instruction at LR=0x81202f18 jumps to PC=0x81216fe8.
• Changing the JIT cache invalidation algorithm to over-invalidate fixes this bug, which makes us think that some stuff which should have been invalidated was in fact not. Making it more precise does not change anything though.
• This is most likely linked to RSO (dynamic loaded libraries for the Wii) usage. Cache invalidation should be done by the OSLink function (which performs relocations then clears the whole RSO code) using ICInvalidateRange, but it does not seem to work on Dolphin for some reason (icbi seems handled correctly).

http://pastebin.com/eG5BhANg

Log of instructions called just before the crash point with over-invalidation (GOOD) and current master (CRASH).

http://delroth.net/icbi.log.xz

Log of all the icbi calls prepended by a timestamp.

http://i.imgur.com/Ukc2N.png

Function at 0x81202e58, which contains nothing that should make it loop to 0x81202e58 as done in current master (according to the first log).

More infos after logging the generated x86 code: just before crashing, 0x81202e58 is indeed re-JITed (cache expired properly), but then the block flows to 0x81202efc and a previous block is used instead of the new code for some reason (why wasn't it invalidated?).

Previous block:

PPC: 81202efc lwz r12, 0x0004 (r4)
PPC: 81202f00 li r3, 0
PPC: 81202f04 li r4, 0
PPC: 81202f08 li r5, 0
PPC: 81202f0c li r6, 0
PPC: 81202f10 mtctr r12
PPC: 81202f14 bctrl

New block which should have been executed instead: see http://i.imgur.com/Ukc2N.png

Data access to 0x81202efc:

• When viewing the game intro video
  -> Call to some CRIWARE archive file loading function (located at 0x803db5bc) which loads data from 0x8118be80 to 0x81261d60 (which is almost exactly sizeof (MovieRR.rso))

• When loading a gamesave
  -> memset(0x8118c080, 0x00, 0x2c5000)

• When loading the (non video) cutscene
  -> memset(0x8118c080, 0x00, 0x2c5000)

• When loading the video cutscene
  -> Call to some CRIWARE archive file loading function (located at 0x803db5bc) which loads data from 0x8118bf00 to 0x81261de0 (which is almost exactly sizeof (MovieRR.rso)), note that this is +0x80 compared to the previous call.

• CRASH

Apparently ICInvalidateRange is never called on 0x81202efc. The file loading function does not do it and then OSLink (called to perform relocations on the RSO) only does ICInvalidateRange on the instructions on which it performed a relocation.

This means the game relies on the icache being too small to remember the instructions at 0x81202efc when it was first executed. However, it looks like jit cache isn't invalidated in case of "natural" icache expiration, and trying to implement that kills performance (because the icache is really small).