EmuNewz Network

Pages: 1 2

Can we possibly have a new release for JPCSP that caters to Kingdom Hearts Birth By Sleep, and overrides the errors? That would be nice, if it were possible. Whenever I (and many other people also) get to Deep Space with Terra, after the cutscene there is supposed to be a huge battle, but the game freezes. I would attach the log, except it won't let me because the file is too large, so I am resorting to Media Fire. I am also going to give you the link to a video that I made that shows exactly what happens and what I do. Note: The game runs more slowly that normal because of the screen capture I was doing.

Link for the .txt file: JPCSP .txt Profiler Link

Link for the video file: JPCSP Kingdom Hearts Birth By Sleep Error Upon Entering Deep Space

If this error could be overrun in a future build or something, that would be greatly appreciated, by many people, myself included.

Another note about the video, I didn't have the media engine or SonicStage enabled. In the video, it showed the cutscene, but if I skip the cutscene, the same thing happens. If I use CWCheat to skip to that event without the cutscene, it freezes in the same way and shows the same message. If I boss warp past that point, then it freezes after I defeat the boss.

Thanks for everything you do JPCSP Devs!

Will it be fixed in newer revisions ? nothing has changed to fix this problem in the last ~50 revs. I know that the network and the fullscreen/resizing fuctions are indev but devs could solve this problem :/ I think this problem is in the complier source file, i've searched on the jpcsp google code.

Thanks

Found the problem. It's this file:

Code:
disc0:/PSP_GAME/USRDIR/MODULE/KEYBLADE_RIDE.ELF

It seems to be using a different kind of relocation...
I'll run a few tests and I'll report back with the results as soon as possible. Wink

(05-21-2011, 05:14 PM)Hykem Wrote: [ -> ]Found the problem. It's this file:

Code:
disc0:/PSP_GAME/USRDIR/MODULE/KEYBLADE_RIDE.ELF

It seems to be using a different kind of relocation...
I'll run a few tests and I'll report back with the results as soon as possible.

Thank you Hykem Smile

If i had a paypal account, i'm sure i would have donate Smile

(i don't know if it's correct, i'm French)

Sorry for the delay on this issue, but this one was quite hard to figure out. Confused

Anyway, I've finally traced this bug by disassembling the compiler's instructions at the problematic execution time:

Code:
85750 [user_main] DEBUG compiler - CodeInstruction.compile  > 0x8B8CCA8 - addiu      $sp, $sp, -16

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCAC - sw         $ra, 0($sp)

85766 [user_main] DEBUG compiler - CodeInstruction.compile <  0x8B8CCB0 - jal        0x08981128

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCB4 - nop

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCB8 - lui        $a1, 0x08B9 <=> li $a1, 0x08B90000

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCBC - addiu      $a0, $v0, -1

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCC0 - sw         $v0, -12888($a1)

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCC4 - sltiu      $a1, $a0, 15

85766 [user_main] DEBUG compiler - CodeInstruction.compile <  0x8B8CCC8 - beq        $a1, $zr, 0x08B8CD18

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCCC - nop

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCD0 - sll        $a0, $a0, 0x0002

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCD4 - lui        $at, 0x08B9 <=> li $at, 0x08B90000

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCD8 - addu       $at, $at, $a0

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCDC - lw         $at, -12952($at)

85766 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCE0 - jr         $at

85782 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CCE4 - nop

85782 [user_main] DEBUG compiler - CodeInstruction.compile  > 0x8B8CD18 - lw         $ra, 0($sp)

85782 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CD1C - jr         $ra

85782 [user_main] DEBUG compiler - CodeInstruction.compile    0x8B8CD20 - addiu      $sp, $sp, 16

85782 [user_main] ERROR compiler - Trying to compile an invalid address 0x02DDF2E0

85782 [user_main] DEBUG compiler - Compilation failed with maxInstruction=3000

85782 [user_main] DEBUG compiler - Compiler.interpret Block 0x8bd1d20

85782 [user_main] INFO  compiler - Compiling for Interpreter _S1_2_8BD1D20

85813 [user_main] DEBUG compiler - // class version 50.0 (50)

// access flags 33

public class _S1_2_8BD1D20 implements jpcsp/Allegrex/compiler/IExecutable  {

  // compiled from: _S1_2_8BD1D20.java

  // access flags 1

  public <init>()V

    ALOAD 0

    INVOKESPECIAL java/lang/Object.<init> ()V

    RETURN

    MAXSTACK = 1

    MAXLOCALS = 1

  // access flags 1

  public exec(IIZ)I throws java/lang/Exception 

    ILOAD 1

    ILOAD 2

    ILOAD 3

    INVOKESTATIC _S1_2_8BD1D20.s (IIZ)I

    IRETURN

    MAXSTACK = 3

    MAXLOCALS = 4

  // access flags 9

  public static s(IIZ)I throws java/lang/Exception 

    GETSTATIC jpcsp/Allegrex/compiler/RuntimeContext.gpr : [I

    ASTORE 4

    ICONST_0

    ISTORE 5

    LDC 146611488

    ILOAD 0

    ILOAD 1

    ILOAD 2

    INVOKESTATIC jpcsp/Allegrex/compiler/RuntimeContext.executeInterpreter (IIIZ)I

    GETSTATIC jpcsp/Allegrex/compiler/RuntimeContext.currentThread : Ljpcsp/HLE/kernel/types/SceKernelThreadInfo;

    DUP

    GETFIELD jpcsp/HLE/kernel/types/SceKernelThreadInfo.runClocks : J

    ILOAD 5

    I2L

    LADD

    PUTFIELD jpcsp/HLE/kernel/types/SceKernelThreadInfo.runClocks : J

    IRETURN

    MAXSTACK = 11

    MAXLOCALS = 13

}

85813 [user_main] DEBUG compiler - Executable: _S1_2_8BD1D20@13ed2e3

85813 [user_main] WARN  hle - 08BD1D2C Unknown instruction 00000000000000000000000000000001 (0x00000001)

143750 [user_main] ERROR compiler - Trying to compile an invalid address 0x00008080

So, that's the trace output that results when the game attempts to interpret this portion of code here:

Code:
08B8CCA8:[27BDFFF0]: addiu      $sp, $sp, -16

08B8CCAC:[AFBF0000]: sw         $ra, 0($sp)

08B8CCB0:[0E26044A]: jal        0x08981128

08B8CCB4:[00000000]: nop

08B8CCB8:[3C0508B9]: lui        $a1, 0x08B9 <=> li $a1, 0x08B90000

08B8CCBC:[2444FFFF]: addiu      $a0, $v0, -1

08B8CCC0:[ACA2CDA8]: sw         $v0, -12888($a1)

08B8CCC4:[2C85000F]: sltiu      $a1, $a0, 15

08B8CCC8:[10A00013]: beq        $a1, $zr, 0x08B8CD18

08B8CCCC:[00000000]: nop

08B8CCD0:[00042080]: sll        $a0, $a0, 0x0002

08B8CCD4:[3C0108B9]: lui        $at, 0x08B9 <=> li $at, 0x08B90000

08B8CCD8:[00240821]: addu       $at, $at, $a0

08B8CCDC:[8C21CD68]: lw         $at, -12952($at)

08B8CCE0:[00200008]: jr         $at

08B8CCE4:[00000000]: nop

08B8CCE8:[0E260447]: jal        0x0898111C

08B8CCEC:[3404000A]: ori        $a0, $zr, 10 <=> li $a0, 10

08B8CCF0:[8FBF0000]: lw         $ra, 0($sp)

08B8CCF4:[03E00008]: jr         $ra

08B8CCF8:[27BD0010]: addiu      $sp, $sp, 16

08B8CCFC:[0E260447]: jal        0x0898111C

08B8CD00:[3404000B]: ori        $a0, $zr, 11 <=> li $a0, 11

08B8CD04:[8FBF0000]: lw         $ra, 0($sp)

08B8CD08:[03E00008]: jr         $ra

08B8CD0C:[27BD0010]: addiu      $sp, $sp, 16

08B8CD10:[0E260447]: jal        0x0898111C

08B8CD14:[3404000C]: ori        $a0, $zr, 12 <=> li $a0, 12

08B8CD18:[8FBF0000]: lw         $ra, 0($sp)

08B8CD1C:[03E00008]: jr         $ra

08B8CD20:[27BD0010]: addiu      $sp, $sp, 16

08B8CD24:[03E00008]: jr         $ra

I've narrowed this down to that particular instruction "08B8CCE0:[00200008]: jr $at". Apparently, at runtime, the register $at contains 08B8CD10.
This causes the execution of "jr $at" to jump to the 0x08B8CD10 address, which in turn contains the instruction "08B8CD10:[0E260447]: jal 0x0898111C".
Now, this should make the compiler jump to the address 0x0898111C, but for some reason it's immediately jumping (not even compiling the delay slot) into 0x08A57578, which contains this:

Code:
08A57578:[8FB00000]: lw         $s0, 0($sp)

08A5757C:[8FB10004]: lw         $s1, 4($sp)

08A57580:[8FB20008]: lw         $s2, 8($sp)

08A57584:[8FB3000C]: lw         $s3, 12($sp)

08A57588:[8FB40010]: lw         $s4, 16($sp)

08A5758C:[8FBF0014]: lw         $ra, 20($sp)

08A57590:[03E00008]: jr         $ra

This is changing the return address to 0x08bd1d20, so the application jumps back to here:

Code:
08BD1D20:[00000000]: nop

08BD1D24:[08B77CB8]: j          0x02DDF2E0

08BD1D28:[00000001]: Unknown instruction 00000000000000000000000000000001 (0x00000001)

08BD1D2C:[00002710]: mfhi       $a0

08BD1D30:[08BD1C80]: j          0x02F47200

08BD1D34:[00000000]: nop

08BD1D38:[00000000]: nop

08BD1D3C:[00000000]: nop

08BD1D40:[00000000]: nop

08BD1D44:[088FF308]: j          0x023FCC20

08BD1D48:[00000000]: nop

08BD1D4C:[08BD97E0]: j          0x02F65F80

08BD1D50:[09FD7960]: j          0x07F5E580

08BD1D54:[09FD7B58]: j          0x07F5ED60

08BD1D58:[0883421C]: j          0x020D0870

08BD1D5C:[00000000]: nop

08BD1D60:[00000000]: nop

08BD1D64:[00000001]: Unknown instruction 00000000000000000000000000000001 (0x00000001)

08BD1D68:[08BD1D20]: j          0x02F47480

08BD1D6C:[00000059]: multu      $zr, $zr

08BD1D70:[00000001]: Unknown instruction 00000000000000000000000000000001 (0x00000001)

08BD1D74:[08B70000]: j          0x02DC0000

08BD1D78:[FFFFFFFF]: vflush

08BD1D7C:[08E47378]: j          0x0391CDE0

08BD1D80:[00000001]: Unknown instruction 00000000000000000000000000000001 (0x00000001)

08BD1D84:[00000000]: nop

08BD1D88:[41205200]: Unimplemented MFC0

08BD1D8C:[00000000]: nop

08BD1D90:[00000000]: nop

08BD1D94:[00000000]: nop

08BD1D98:[BF80419A]: Unknown instruction 10111111100000000100000110011010 (0xBF80419A)

08BD1D9C:[00000000]: nop

08BD1DA0:[00000000]: nop

08BD1DA4:[00000000]: nop

08BD1DA8:[BF800000]: Unknown instruction 10111111100000000000000000000000 (0xBF800000)

08BD1DAC:[00000000]: nop

08BD1DB0:[00000000]: nop

Weird, huh? Either the game forgot to load something at that address, or something is quite wrong with our compilation sequence (most likely Tongue

(05-29-2011, 07:01 PM)Hykem Wrote: [ -> ]Weird, huh? Either the game forgot to load something at that address, or something is quite wrong with our compilation sequence (most likely ).

Could you enable "debugCodeBlockCalls = true" in RuntimeContext.java, line 68 and post a log file including compiler and runtime logs at DEBUG level? This way, I can see what the compiler generated and which call sequences are executed.

Thanks!

(05-29-2011, 07:42 PM)gid15 Wrote: [ -> ]
(05-29-2011, 07:01 PM)Hykem Wrote: [ -> ]Weird, huh? Either the game forgot to load something at that address, or something is quite wrong with our compilation sequence (most likely ).
Could you enable "debugCodeBlockCalls = true" in RuntimeContext.java, line 68 and post a log file including compiler and runtime logs at DEBUG level? This way, I can see what the compiler generated and which call sequences are executed.

Thanks!

Sure.

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).

(05-29-2011, 08:45 PM)Hykem Wrote: [ -> ]Sure.
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).

The only information I could find in the log was that the address 0x8B8CD10 was compiled as a "nop" some time before:

Code:
Replacing CodeBlock at 0x08B8CD10 by Native Code 'nop'

Which means that at that time, the code at 0x8B8CD10 was

Code:
0x8B8CD10 jr $ra

0x8B8CD14 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.
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?

(05-30-2011, 07:25 AM)gid15 Wrote: [ -> ]
(05-29-2011, 08:45 PM)Hykem Wrote: [ -> ]Sure.
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).
The only information I could find in the log was that the address 0x8B8CD10 was compiled as a "nop" some time before:

Code:
Replacing CodeBlock at 0x08B8CD10 by Native Code 'nop'
Which means that at that time, the code at 0x8B8CD10 was

Code:
0x8B8CD10 jr $ra 0x8B8CD14 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.
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. Tongue

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. Wink

Wow thanks devs, somebody posted a problem, and you fixed it. Way to go!

Pages: 1 2

chessplayerjames

-Kratos-

Hykem

-Kratos-

Hykem

gid15

Hykem

gid15

Hykem

ventusrocks