So I was doing some Gu tests today ... Must have messed up somewhere because I crashed with a bus error (data), using PSPlink.
Anyway, I didn't think much of it, then something caught my eye ....
Exception - Bus error (data)
Thread ID - 0x04E7AA45
Th Name - user_main
Module ID - 0x04E8180D
Mod Name - "copyimagetest"
EPC - 0x08895478
Cause - 0x0000001C
BadVAddr - 0x00000C00
Status - 0x20008613
zr:0x00000000 at:0x088A0000 v0:0x00000000 v1:0x00000001
a0:0x00000000 a1:0x00000000 a2:0x00000000 a3:0x00000000
t0:0x0000001C t1:0x00000007 t2:0x88011CC8 t3:0x88011CC8
t4:0x09DFFD50 t5:0x00000E00 t6:0x08898960 t7:0x00008600
s0:0x000000A0 s1:0x00000090 s2:0x00000000 s3:0x09EFFEE0
s4:0x09DFFDD8 s5:0x00000013 s6:0xDEADBEEF s7:0xDEADBEEF
t8:0x00000000 t9:0x00058680 k0:0x09EFFF00 k1:0x00000000
gp:0x088A78C0 sp:0x09DFFD90 fp:0x09EFFEA0 ra:0x08895438
Load/Start ms0:/GFXTEST.PRX UID: 0x04E8180D Name: "copyimagetest"
Have a look at the s6 and s7 registers... Is this some kind of sick Sony developer joke? Or did I just do something bizarre and wind up with the creepiest exception trace ever?
I remember a sat reciver firmware that contained DEADCAFE... It turned out that CAFE was a bootloader password one had to enter (rs232 interface + keypressing on the reciver to start the bootloader) to get into bootloader mode and be able to flash a dead reciver (dead as badly flashed)... Wonder if SONY would leave the same clue...
Dream on, 0xDEADBEEF (together with 0xBAADFOOD, 0xBD.. to 0xFD.. (win32 crt) and others) are very common memory fill codes used for debugging purposes.
Actually this is something often used by memory managers, to mark
beginning and ends of allocated memory regions for debug purposes. So
whenever the MM is requested to allocate x bytes, it actually allocates
x + 2*y, fills the first and last y bytes with a easily recognizeable
bits (0xDEADBEEF, 0xBAADF00D, etc.) and returns a pointer to x+y to the
caller.
Now whenever the memory is about to be freed or the application crashes,
it prints out these first and last y bytes of the used memory region,
and if these have different bit patterns, then you know that somewhere
in the program you access unallocated memory.
In your case you seem to have accessed such memory also, which probably
causes the crash, though I'm not sure if this memory marking is done by
the PSP, the SDK or PSPLink.
Well in this situation 0xDEADBEEF is actually the default register value the kernel sets when a new thread is created, some of the registers have not been used during the running of the application and that is why some of them are set to that value.
