jak-project
jak-project copied to clipboard
open-goal
[jak2] overlord crash in `ruins-mech` (speedrun route)
This happens when doing it the speedrunner way (the hut is not loaded in fully). I've narrowed down a few things, but still not the true root-cause for why things get into this state.
So first off, the crash is here in the memcpy in sceSdVoiceTrans:
the channel and the iop_addr seem all wrong here
Stepping back up the chain, this only happens when the dma code receives a VagCmd with the name ruins-pillar-collapse-1. This command is inconsistently received (it doesn't happen every time) -- and the game only crashes when it gets this command.
My naive assumption is that in the original game this exact same thing happens, but the game timeouts gracefully. Notice how in a normal speedrun, loading this cutscene takes a considerable amount of time: https://youtu.be/HYTg_dNDdv8?t=516
I was able to prevent the crash (but i wouldn't be surprised if this causes other issues) by returning early from the DMA code if a channel below 0 is received. This kinda breaks the cutscene, but atleast it does not crash:
https://github.com/open-goal/jak-project/assets/13153231/65ff0982-9e0b-4f2d-a74a-1aa9f703cd1b
the cutscene starts paused and skips on it's own
Doesn't seem like the real implementation of sceSdVoiceTrans does any sanity checking on arguments other than the size. Given these parameters I'm pretty sure it would actually perform the DMA from 0x0 using SPU core 1 (channel: -1 & 1).
Idk if that's actually what happens on real hw though.
I always assumed the slow loading times was due to sagehut needing to be loaded, as you skip all its loading triggers. This could perhaps be related, but would be weird because the same situation happens... whenever you select anything from the scene player.
And on a related note, address 0 is valid in the IOP and will not segfault on read/write. So an invalid memcpy from there would not cause a crash but likely just fill the buffer with garbage.