(05-30-2011, 07:25 AM)gid15 Wrote:(05-29-2011, 08:45 PM)Hykem Wrote: Sure.The only information I could find in the log was that the address 0x8B8CD10 was compiled as a "nop" some time before:
To save space, I've tried to make the log as specific as possible. Here is a DEBUG level Compiler and Runtime log file recording the activity of the thread "user_main" alone, shortly after loading the KEYBLADE_RIDE.ELF.
As you can see, for some reason, there seems to be some sort of conflict with the runtime call instructions and the respective compiled jump (the one with the $at register).
Which means that at that time, the code at 0x8B8CD10 wasCode:Replacing CodeBlock at 0x08B8CD10 by Native Code 'nop'
It seems that this code has been replaced with another sequence but it looks like the compiler is still using the old compiled code.Code:0x8B8CD10 jr $ra
0x8B8CD14 nop
Normally the compiled code is invalidated (RuntimeContext.invalidateAll) when unloading a module (sceKernelUnloadModule)... Does this game call a different method to unload the module located at 0x8B8CD10?
Could you set a memory write breakpoint at 0x8B8CD10-0x8B8CD17 to find out who is overwriting the memory?
Uh oh, found the problem...
This game is using sceKernelIcacheInvalidateRange to invalidate the memory area where the ELF file will be read into.
Then, when the next ELF file is read, no module loading is processed, the contents are just overwritten and the range is recompiled *facepalm*.
Going to implement this right away and also improve a bit our trace debug for some of these cache functions (missing params in some of them).
EDIT:
Finally, this is with chessplayerjames' save file, after the bug. Commiting the fix right now.