3rd Birthday crash in second mission when fast memory and JIT on

[sum2012]

EDIT:Correct the google share setting.
After enter door will crash when fast memory and JIT on

save status:
https://drive.google.com/file/d/0B3OaSdeV0L8kcU0zcVVnbzFCc1k/edit?usp=sharing

crash trace

ppsspp Debug log v0.9.8-242 (stop when invalid address)
https://drive.google.com/file/d/0B3OaSdeV0L8kZnRKdG4zbDZHaEU/edit?usp=sharing

[raven02]

I just tried the savestate as well .If turn off JIT but keep fast memory ON , it is okay not crashing but noth both

[sum2012]

Thanks @raven02
Updated tite

[hrydgard]

Fast Memory is mostly ignored when the JIT is off, so that's not surprising...

[i30817]

Yes, i noticed this too, but didn't report. Crashes on exit on most times. I managed not to make it do that on the first transition by waiting a bit (i was thinking it was the music, although the stacktrace is useless JIT) but it always crashed on the second transition.

[unknownbrackets]

Since there was another one like this, does this also happen with PSP Model set to PSP-1000? Note that you cannot load a savestate when you change PSP model, you'll have to use a save game.

-[Unknown]

[i30817]

I don't have the game, or the saves anymore, one of the reasons i didn't report (the other the stacktrace being useless).

[sum2012]

@i30817 You need turn off fast memory and JIT to make stacktrace.
Luckly today is Sunday to test again
edit:TEST on ppsspp-v0.9.8-249-g8a440f9 still crash

[unknownbrackets]

Well, knowing that it crashes in Comp_ITypeMem or w/e is pretty much zero help. It would be useful to know if it crashed somewhere that jit being on tells about.

Also, if you are using "Read framebuffers to memory", please expect crashes. I recommend reading that setting name as "Make some graphical issues go away, but cause other graphical issues and also cause crashes." Unfortunately, that's a bit too long to fit in the settings window.

If it crashes without a stack trace with jit on and with "buffered rendering" only, use these settings:

• Jit: on (off is WORSE)
• Debug -> Ignore Illegal Reads/Writes: off (IMPORTANT)
• Fast memory: off (IMPORTANT)

After setting those settings, select Debug -> Disassembly... and play until it stops working - we have to know why the game's code is telling PPSSPP to do such a stupid thing as accessing an invalid address. The game's code is what's crashing, so the game's code is what needs to be debugged.

If a game accesses such an address on a PSP, it will also crash. That is correct behavior. So you'll get pretty much nowhere puzzling over a stack trace from the interpreter, because you'll just discover that it's doing the right thing.

-[Unknown]

[sum2012]

@unknownbrackets PSP-Model 1000 also crash
Save status:
https://drive.google.com/file/d/0B3OaSdeV0L8kRVZuWWRtdGNCS0E/edit?usp=sharing
log: https://drive.google.com/file/d/0B3OaSdeV0L8kWDhZdVRHbHkyRlE/edit?usp=sharing

[sum2012]

@unknownbrackets It is your instruction of PSP-Model 1000
edit:add dism: https://gist.github.com/sum2012/a3813c3c76053a7bcfae

[unknownbrackets]

Well, a2 is being read from near s3, which looks like a valid address. So something is writing garbage to s3. Probably read frambuffers to memory. Note that loading a savestate will load the garbage to this address. Turning off framebuffers to memory won't erase the garbage.

-[Unknown]

[sum2012]

@unknownbrackets ok,I re-do it.
Note that I confirm it is buffered rendering

[sum2012]

@raven02 @i30817
This is the game save after first mission.
Please use @unknownbrackets instruction to debug.
I may hard to win without saves tatus so that I share the save with you.

https://drive.google.com/file/d/0B3OaSdeV0L8kNGhOLURTRHFNcU0/edit?usp=sharing

[sum2012]

@unknownbrackets s3 seem the same value without savestate

[unknownbrackets]

There's no way to save mid-mission, right, without using savestates? I have not played this game much.

I think I just reproduced it from a clean save.

-[Unknown]

[sum2012]

Tested real PSP do not crash
JPCSP do not have error\warning log

[unknownbrackets]

I think it has something to do with sceDmacMemcpy. It does not happen every time, especially if you overdrive in between. I have a savestate right near an exit it happens at, but if I overdrive first, it doesn't happen. This is not the case with your savestate afaict.

Right before one error, I got an sceDmacMemcpy warning about two writes near each other. Could be a timing issue.

-[Unknown]

[unknownbrackets]

0x0922AF98 [=0x0e7ee218]

CRASH:
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af98 ((0922af98)), PC=08b54f5c (z_un_08b54d24)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af99 ((0922af99)), PC=08b54f64 (z_un_08b54d24)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af9a ((0922af9a)), PC=08b54f70 (z_un_08b54d24)
user_main    W[HLE]: HLE\sceDmac.cpp:84 sceDmacMemcpy(dest=0905aac0, src=091bfc40, size=6528): overlapping read
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=0905c440, src=092e4180, size=1157184)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09176c80, src=093fe9c0, size=48832)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09182b40, src=0940a880, size=46912)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=0918e280, src=09415fc0, size=18816)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09192c00, src=0941a940, size=787968)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write6303744 at 09192c00 ((09192c00)), PC=08b1f4ec (z_un_08b1f4a4)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09253200, src=094daf40, size=21696)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=092586c0, src=094e0400, size=40512)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09262500, src=094ea240, size=40512)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Read32 at 0922af98 ((0922af98)), PC=08b6131c (z_un_08b61250)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write32 at 0922af98 ((0922af98)), PC=08b61328 (z_un_08b61250)
idle0        N[MM]: Debugger\Breakpoints.cpp:41 CHK Read32 at 0922af98 ((0922af98)), PC=08b60198 (z_un_08b60140)
idle0        W[MM]: MemmapFunctions.cpp:94 ReadFromHardware: Invalid address 0e7ee218

GOOD:
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af98 ((0922af98)), PC=08b54f5c (z_un_08b54d24)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af99 ((0922af99)), PC=08b54f64 (z_un_08b54d24)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write8 at 0922af9a ((0922af9a)), PC=08b54f70 (z_un_08b54d24)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=0905aac0, src=091bfc40, size=6528)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=0905c440, src=092e4180, size=1157184)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09176c80, src=093fe9c0, size=48832)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09182b40, src=0940a880, size=46912)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=0918e280, src=09415fc0, size=18816)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09192c00, src=0941a940, size=787968)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write6303744 at 09192c00 ((09192c00)), PC=08b1f4ec (z_un_08b1f4a4)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09253200, src=094daf40, size=21696)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=092586c0, src=094e0400, size=40512)
user_main    N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=09262500, src=094ea240, size=40512)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Read32 at 0922af98 ((0922af98)), PC=08b6131c (z_un_08b61250)
user_main    N[MM]: Debugger\Breakpoints.cpp:41 CHK Write32 at 0922af98 ((0922af98)), PC=08b61328 (z_un_08b61250)
SQEX FILE RE N[HLE]: HLE\sceDmac.cpp:88 sceDmacMemcpy(dest=08400000, src=09cdc040, size=85920)

So the problem is when idle0 is trying to read the value... probably a GE signal issue.

Hmm, not sure. It reads from a different address when it doesn't crash, because s3/a1 have different values.

-[Unknown]

[unknownbrackets]

I'm not sure what's correct, but not triggering SYNC ge signals fixes it. So probably it is an issue with how they are handled...

-[Unknown]

[kaienfr]

I suggest just firstly find which version is not crashed, and bisection the problem commit which will much more easily to locate the issue.

[unknownbrackets]

Since it's not consistent, it may just be that it was always happening. Interacting with certain objects and causing certain drawing behaviors seems to affect it.

So, I think that the GE issues an interrupt whenever a GE_CMD_END is hit. I guess practically, this doesn't matter to us...

It seems like the SYNC signal type is meant as a barrier, e.g. to ensure the CPU is aware of things written by the GE, or else the GE is aware of things written by the CPU. It happens upon the FINISH following the sync.

PAUSE has similar semantics; it pauses the list upon the next FINISH. I can't figure out how to unpause though.

Anyway, I played a bit (though the first couple episodes) and can't reproduce it anymore with sync not sending an interrupt, but theoretically, that should have no effect, except causing other interrupts to happen at a different time. I'm worried it's a more complex timing issue...

-[Unknown]

[sum2012]

Well done @unknownbrackets

[KittyOfPrincess]

Hi, I'm not very familiar with your terminologies here. But, I'm having the same problem with 3rd birthday using ppsspp ver. 0.9.8. Uhm, how can I fix this?

[Bigpet]

@KittyOfPrincess use a newer version of PPSSPP