Kirameki School Life SP won't get in-game, black screen.

[ghost]

Update - Now, this game is Playable (#1550 (comment))

After the recent fix (#1532), it's possible to see the main menu and game settings but when I try to start playing, the game stops working and the screen freezes to black.
Two screenshots of the console:

25 MB of log here:
http://limelinx.com/fp4am

[unknownbrackets]

Well, the problem is the NULL pointer jump. It'd be nice to see the log before the first invalid memory access (you can make it stop emulation at the first one with the last option under Options.)

-[Unknown]

[ghost]

Unchecking "Ignore illegal red/writes" now the log is 8 MB but the game didn't load the the first screen before it happened, I'm posting it in 5 mins. Some screens:

Two invalid syscalls (they were happening since before, every time the emu loads the ISO):

Screenshot where the first invalid memory access happened:

[ghost]

I just noticed that clicking "no" when the syscall appears, Visual C++ starts reporting things. I think it's a different problem, should I leave that for another issue?

By the way, the new 8 MB log is here:
http://limelinx.com/eld8u

I'll try again leaving the invalid addresses ignored and enable them only before the black screen appear.

[unknownbrackets]

Hmm, well, it's probably related.

This first issue seems psmf related. It's hard to say if it's impacting stuff later or not. Probably because we make the psmf end immediately and the game was not expecting that.

For the unknown syscalls, can you paste the .map file (save from the Debug menu in the emulator) in a gist or pastebin? Or else, the log - it has the bad syscalls at the top too.

We should at the very least stub them.

-[Unknown]

[ghost]

Confirming that the syscalls are a thing of this game, they aren't happening when I load Fate/EXTRA CCC or Amagami EbiKore Plus. While, if I try to load Boku wa Tomodachi ga Sukunai (which is made by the same producers of Kirameki), the unknown syscalls happen again. I'll post all details from VC++ in 5 mins.

[ghost]

Unknown Syscall stack trace:
http://pastebin.com/P2gHe2Ef

Log generated until now (it's paused since I clicked "no" in the first syscall window):
http://pastebin.com/WviTaC1L

I can't see or click the emulator window for some reason while the debug is paused, I'll try to save a map file in some way.
Here some screenshot including the auto/local variables of each trace:
http://limelinx.com/cd3a2

EDIT: I forgot to say, this is all about only the first syscall, to get the details of the second I think I've to resume the debug, if you don't need more details for the first one. I'm going to get some pizza, brb 30-40 mins (I'll leave everything running so if you need more details just write it here).

[unknownbrackets]

Here are the syscalls. In this case, the stack trace isn't very interesting because I know where it generates the message that the syscall is unknown.

41:40:449 hle\hle.cpp:227 I[HLE]: Syscall (sceMp4,68651cbc) unresolved, storing for later resolving
41:40:449 hle\hle.cpp:227 I[HLE]: Syscall (sceMp4,9042b257) unresolved, storing for later resolving

Hmm. Those are sceMp4Init and sceMp4Finish respectively, according to Google. You could try creating stubs for them in sceMpeg let's say, and returning either 0 or -1 and see if they change anything.

To do this, you'd have to add a couple things, but it's not too hard:

1. Add a table to Core/HLE/sceMpeg.cpp like the others, will start like this:

const HLEFunction sceMp4[] =
{
    {0x68651cbc, 0, "sceMp4Init"},
    {0x9042b257, 0, "sceMp4Finish"},
}

1. Add a register function to sceMpeg.cpp for sceMp4, again like the others:

void Register_sceMp4()
{
    RegisterModule("sceMp4", ARRAY_SIZE(sceMp4), sceMp4);
}

1. Add that function to sceMpeg.h as well.
2. Add a call to Register_sceMp4(); from Core/HLE/HLETables.cpp right next to the sceMpeg one.

At this point it'll stop warning about the syscall. Then you can stub them by changing the table:

const HLEFunction sceMp4[] =
{
    {0x68651cbc, WrapI_V<testfunc>, "sceMp4Init"},
    {0x9042b257, WrapI_V<testfunc>, "sceMp4Finish"},
}

Above that add the func:

int testfunc()
{
    return 0;
}

Returning 0 or -1 there might help the game, or it might do nothing. More correctly, there would be two functions, sceMp4Init and sceMp4Finish, and they would have parameters (and the WrapI_XXX would be changed to match the parameter types.)

-[Unknown]

[hrydgard]

@unknownbrackets , with that much work on a post you might as well have sent a pull request :) Adding those stubs shouldn't hurt.

[unknownbrackets]

Heh, but it sounds like @KyousukeKyaa is interested in debugging it. I think it's more fun that way.

-[Unknown]

[ghost]

I'll try, it's a chance to learn something about MS Visual C++.

I did it untill phase 4 ("Add a call to Register_sceMp4(); from Core/HLE/HLETables.cpp right next to the sceMpeg one") and tried to continue the debug before changing the table (at this point I had to do it, right?) but VC++ said there were 3 errors:

I tried once again to resume the debug without modifying anything and the whole screen went black for a few seconds, then the second syscall window appeared (I guess it worked!). Now I'm going to change the table as you wrote and then I'll post more details about the second syscall.

[unknownbrackets]

In sceMpeg.h, you want it to look like the sceMp3 and sceMpeg ones - that is, with just a ; at the end.

-[Unknown]

[ghost]

My fault, did it have no effect then? if so I've to restart again the debug from the first syscall.

[unknownbrackets]

Yeah, it didn't compile so it ran the old version I think.

-[Unknown]

[ghost]

I tried again using ; at the end and moving the position of the code (it was after sceMp3 and now is above, between sceMpeg and sceMp3) but it's giving the same error messages, maybe I did it wrong in the other files?

This is the modified sceMpeg.h:
http://paste.ofcode.org/BCH23qc4W7gaQnmDN2bkCs

HLETables.cpp
http://paste.ofcode.org/4a79DnxpxnB7MG6GBceTJb

sceMpeg.cpp:
http://paste.ofcode.org/i8W5UaRiJyjdg3TCM9Rs4a

Is there any syntax error?
Error 5: Function 'void Register_sceMp4 (void)' already has a body (sceMpeg.cpp)

[unknownbrackets]

The .h file is a "header" file, it just defines the names of functions. It should just look like this:

void Register_sceMp4();

Without the part inside the { }s. But the .cpp file is for the code, it should have the { }s and no ;

The other files look okay.

-[Unknown]

[ghost]

Omg I didn't get it before /facepalm now I understand. In facts, it works now even though it returns this:
Error 1 A global or static variable has been added: sceMp4 (reference in c: \ users \ kyousuke \ desktop \ ppsspp \ extra \ master \ ppsspp \ core \ debug \ scempeg.obj)

I guess that's because I didn't change the table yet, going to do it now.

[unknownbrackets]

Hmm, that's strange. I've never seen that error before... It's true that a global static variable was added though... not sure why it's an error.

But yeah, might help to try the table. Are you restarting the emulator when changing the code? If not, that could be why as well.

-[Unknown]

[ghost]

👍 yep it was that, I had to stop the debug and start a new one and this time with the modified table there were no syscalls... Approved!

Now, back to the in-game problem! xD

[ghost]

Just tried to play, in the main menu I unchecked "Ignore illegal reads/writes" before pressing x (or O on the psp interface) and this invalid access appeared in the console after pressing x:

This is the map file:
http://paste.ofcode.org/U2bP7kZsap3svJN9FWZFr7

Log here:
http://limelinx.com/dv3q2

[unknownbrackets]

So if you want to give it a shot (and split it into two functions like the rest), it might be good to commit and send a pull request. It should have a comment that the parameters aren't filled in yet and probably an ERROR_LOG inside it (like many other functions.)

About the next problem (memory error), let's take a look at Core/HLE/scePsmf.cpp (it appears twice):

    // TODO: Once we start increasing pts somewhere, and actually know the last timestamp, do this better.
    psmfplayer->status = PSMF_PLAYER_STATUS_PLAYING_FINISHED;

This is probably too early. For now (as a hack you wouldn't necessarily want to send a pull for), maybe try:

    // TODO: Once we start increasing pts somewhere, and actually know the last timestamp, do this better.
    static int numCalls = 0;
    if (++numCalls > 1000)
        psmfplayer->status = PSMF_PLAYER_STATUS_PLAYING_FINISHED;

The idea here is that after the game calls this 1000 times, it will end the video. This might be long enough that something else the game is expecting to happen will work out.

This isn't really a proper fix, but it can eliminate whether or not this is even causing the later problem or not (if it makes the memory access errors go away.) If those errors go away, but it still dies at the menu, that means the menu has a different problem.

-[Unknown]

[ghost]

I applied that change to the file and ran a new test without ignoring illegal reads/writes, but the same error appeared in the console (core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 50bf37a8).
Then I tried once again, this time ignoring illegal reads/writes the screen didn't go black right away but after some second (it freezed on the main menu) and the console stopped like this:

Log here:
http://limelinx.com/b98e2

The map file is identical to the previous one:
http://paste.ofcode.org/U2bP7kZsap3svJN9FWZFr7

By the way, I'm still using that zip from the outdated revision, is that alright or is better to continue using the latest zip?

[unknownbrackets]

The map file won't change, it just shows what functions the game uses. I guess it could change if it loaded more modules.

Well, I'd suggest using GitHub for Windows, which can update without redownloading everything from scratch. It's pretty easy to use too. But, you can stick with this version or download the latest, either way.

Anyway, it's very interesting if this changed the behavior later on.

The reason I suspect it may be related to psmf is this in the log:

28:35:518 Test Thread  E[HLE]: hle\scepsmf.cpp:650 UNIMPL scePsmfPlayerStop(08bfa620)
28:35:518 Test Thread  E[HLE]: hle\scepsmf.cpp:754 UNIMPL scePsmfPlayerReleasePsmf(08bfa620)
28:35:521 Test Thread  D[HLE]: hle\scekernelthread.cpp:2340 sceKernelWaitThreadEndCB(364, 0x0)
28:35:521 Test Thread  D[HLE]: hle\scekernelthread.cpp:2340 sceKernelWaitThreadEndCB(365, 0x0)
28:35:521 Test Thread  D[HLE]: hle\scekerneleventflag.cpp:339 sceKernelCancelEventFlag(362, 00000001, 09FAF2B0)
28:35:521 Test Thread  D[HLE]: hle\scekernelthread.cpp:2340 sceKernelWaitThreadEndCB(363, 0x0)
28:35:521 Test Thread  E[HLE]: hle\scepsmf.cpp:650 UNIMPL scePsmfPlayerStop(08bfa620)
28:35:521 Test Thread  E[HLE]: hle\scepsmf.cpp:754 UNIMPL scePsmfPlayerReleasePsmf(08bfa620)
28:35:522 Test Thread  D[HLE]: hle\scekernelthread.cpp:2007 sceKernelDeleteThread(365)
28:35:522 Test Thread  D[HLE]: hle\scekernelthread.cpp:361 Freeing thread stack audioThread
28:35:522 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:522 Test Thread  D[HLE]: util\blockallocator.cpp:217 Block Alloc found adjacent free blocks - merging
28:35:522 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:523 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 0000000c
28:35:523 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 00000008
28:35:523 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 0000000c
28:35:523 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 00000008
28:35:523 Test Thread  D[HLE]: hle\scekernelthread.cpp:2340 sceKernelWaitThreadEndCB(364, 0x0)
28:35:523 Test Thread  D[HLE]: hle\scekernelthread.cpp:2007 sceKernelDeleteThread(364)
28:35:523 Test Thread  D[HLE]: hle\scekernelthread.cpp:361 Freeing thread stack displayThread
28:35:523 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:523 Test Thread  D[HLE]: util\blockallocator.cpp:217 Block Alloc found adjacent free blocks - merging
28:35:524 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:524 Test Thread  W[MM]: core\memmapfunctions.cpp:91 ReadFromHardware: Invalid address 50bf37ac
28:35:524 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address a008c3af
28:35:524 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 0008b0aa
28:35:524 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 50bf37a8
28:35:525 Test Thread  D[HLE]: hle\scekerneleventflag.cpp:339 sceKernelCancelEventFlag(362, 00000001, 09FAF2C0)
28:35:525 Test Thread  D[HLE]: hle\scekernelthread.cpp:2340 sceKernelWaitThreadEndCB(363, 0x0)
28:35:525 Test Thread  D[HLE]: hle\scekernelthread.cpp:2007 sceKernelDeleteThread(363)
28:35:525 Test Thread  D[HLE]: hle\scekernelthread.cpp:361 Freeing thread stack modeThread
28:35:525 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:526 Test Thread  D[HLE]: util\blockallocator.cpp:217 Block Alloc found adjacent free blocks - merging
28:35:526 Test Thread  D[HLE]: util\blockallocator.cpp:205 Merging Blocks
28:35:527 Test Thread  D[HLE]: hle\scekerneleventflag.cpp:380 sceKernelDeleteEventFlag(362)
28:35:528 Test Thread  D[HLE]: hle\scekernelmutex.cpp:775 sceKernelDeleteLwMutex(08bf3754)
28:35:531 Test Thread  W[MM]: core\memmapfunctions.cpp:91 ReadFromHardware: Invalid address 50bf37ac
28:35:531 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 50bf37a8
28:35:533 Test Thread  D[HLE]: hle\scekernelmutex.cpp:775 sceKernelDeleteLwMutex(08bf3714)
28:35:533 Test Thread  W[MM]: core\memmapfunctions.cpp:91 ReadFromHardware: Invalid address 50bf37ac
28:35:533 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 50bf37a8
28:35:535 Test Thread  I[HLE]: hle\scepower.cpp:209 sceKernelVolatileMemUnlock(0)
28:35:535 Test Thread  E[HLE]: hle\scepsmf.cpp:721 UNIMPL scePsmfPlayerDelete(08bfa620)

...

28:46:954 Test Thread  W[MM]: core\memmapfunctions.cpp:123 WriteToHardware: Invalid address 50bf37a8
<death>

Notice the "50bf37a8" (which is definitely a totally invalid memory address) looks similar to the addresses used earlier. Even if it's not caused by scePsmf bugs, the bad address probably "originates" there. We know the game isn't supposed to hit those, because it'd crash if it hit them on a real PSP.

Unfortunately, I don't see why it's trying those addresses...

-[Unknown]

[ghost]

About the sceMp4 commit, can I send directly a pull request with the final version of the code (the modified table and int return 0) or it has to be done in two times, like I did when I was debugging?

EDIT: I missed the raven02 commits, ok.

[unknownbrackets]

Well, it can be just once, but it seems @raven02 was watching this issue and beat you to it (see #1558.)

-[Unknown]

[ghost]

I was writing about the first invalid address but I think I deleted my post accidently. Anyway, there's another invalid address that happens before the "press any button" screen (before reaching main menu), it might be related to the intro video that's supposed to appear at that point.

Console:

I was ignoring this before because I was focusing on the "getting in-game", when you wrote it appears twice were you referring to that?

Log:
http://limelinx.com/er85q

[unknownbrackets]

Right, well, if you look at the log (as posted above), it's clustered shortly after a sceKernelDeleteThread(), which is interesting. The second and third set have the same address that crashes later, so it's probably related...

It kinda gets hard here, finding where the memory address comes from...

-[Unknown]

[ghost]

Something new just happened, I never tried to see what happens clicking on the other 2 options from main menu while debugging, so far I just browsed the settings and tried to start the game, I totally forgot about them..

Clicking the bottom-right selection in main menu (ignoring illegal reads/writes), returns this loop in the console:

The log file is over 200MB I'll try to split it in 15-20 parts if you want to browse it.
Anyway, I had to close the PPSSPPdebug.exe window to stop it and when I did it, visual c++ reported this:

Pasted here:
http://pastebin.com/3YGqyTaB

I'm taking screenshots for each trace and the respective variables, I'll post in 5-10 mins.

[unknownbrackets]

Weird, hard to say. It crashed trying to save ppsspp.ini.

Something is definitely not going the game's way as far as memory addresses... anyway, what's most interesting is the syscalls before those bad memory addresses start. Usually (not always, just usually) it's related to a syscall it just called.

-[Unknown]

[ghost]

Screens here:
http://limelinx.com/w5fy

Until now the syscall window didn't pup up, maybe if the debug continues.
I don't know what that option does (can't read japanese yet) but this is what happens when I click it in JPCSP:
(EDIT: I found that インス卜ール means "Install Book" or something like that)

After loading:

Generates a 392MB file "RES.DAT" under "...\JPCSP\ms0\PSP\SAVEDATA\ULJS00458DAT"

[ghost]

Ok I ran 3 tests, the first using -1 and there were some graphic glitch (random text appearing on the screen for a shot time), the console returned this:

Log and details: http://limelinx.com/dit4m

The second time (keeping -1) with the modified sceKernelThread.cpp the result was:

Log here: http://limelinx.com/ls9i

The third test was same as the second, only changing -1 back to 0:

Log and details: http://limelinx.com/dkzae

I'll try again 4 tests ignoring the invalid addresses.

[ghost]

Done 6 tests, it took a while because I messed up the screenshots but, was a good thing in its own way.

1. The first test was simple, using return 0 like the original file and the result was a loop in the console but I forgot to take a screenshot, it was similar (if not identical) to this: Kirameki School Life SP won't get in-game, black screen. #1550 (comment)

Log and infos: http://limelinx.com/b5q5i

2. I ran another test always using return 0 because I wanted to take some screenshot, but it went different and didn't loop:
   

Log and infos: http://limelinx.com/cq6ra

3. The third (using return -1), I had to do it twice (like the 1st) because the screenshots were accidently deleted, but that was a good thing because when I did it a second time, finally VC++ returned something.
   Anyway, this is the first one, which wasn't much different from the others (no screens):
   Log and infos: http://limelinx.com/dcmc2

4)This is the interesting one (always using return -1), the console started looping this:

When I closed PPSSPPDebug.exe, VC++ reported something:
http://pastebin.com/V0K7T5Rj

Log and infos about the stack trace: http://limelinx.com/e4w6e

5. This test was done using return -1, plus the modified code in sceKernelThread.cpp.
   Console:
   

Log and infos: http://limelinx.com/flhy

6. The last was the same as the 5th, but using return -0 (yes negative zero, my fault):
   

Log and infos: http://limelinx.com/003q

[unknownbrackets]

Hmm, strange. Interesting that so many different things can happen, but I don't know why, yet, sorry.

-[Unknown]

[ghost]

Did that log from VC++ contain anything new? I couldn't save any screenshots of the auto variables, for some reason the window is totally disappeared from VC++ interface, I'm still trying to understand what I did wrong.

Now I'm converting a gameplay video for YT, it should be ready in 30-40 mins if you want you can check it later. It was recorded from the beginning, to the part where the prologue ends, it might help to better understand how this game works.
Also, there's a graphic glitch (even though it's nothing new, is the same glitch of Boku wa Tomodachi ga Sukunai and it's there since the first time I tried that game) that happens whenever a 3d model is loaded, can't explain it very well because it's just a black square but, you'll understand watching the vid (in the beginning).
The video is based on r266 (232b354) from orhpis.

EDIT: Link to the vid:
https://www.youtube.com/watch?v=FTJv4seNoro

About the log, it's filled with lines like these (I think the same as before):
http://pastebin.com/0FDE0WEz

Download: http://limelinx.com/erft6
Probably it's not very useful but, it's the log of that game session so I thought they should be posted together.

This game is funny, in 2 different ways: for the game contents and for the strange things that it's asking to the emulator.
I'm not sure if the random events in game are a good thing (cannot keep track of things) but I'm going to try anyway, if something different comes out I'll let you know, and if you've any new idea let me know too, I like playing this galge and to mess with VC++ so it's no problem (once I manage to fix the compiling error problem).

---

I think VC++ won't work for a while, I should /format to fix the error problem but atm I don't have the windows 7 installer dvd here, it's gonna take a while.

[ghost]

I didn't restore VC++ yet but, I can use the debug console playing the Orphis' builds for now, just tried r382 (e23b226)
And the invalid address was the same as before:

Log: http://limelinx.com/emli6

Then, reading MemmapFunctions.ccp (li 91) it's something related to JIT, so I tried playing again disabling JIT from the game options and the result was different, the game lagged a lot and there were glitches in the colors, the console reported different things.
Here 2 screens (the first one was taken a few seconds after loading the ISO, the second when the game stopped on loading screen after playing a few minutes):

Log: http://limelinx.com/cwfvm
Did you find anything about the ReadFromHardware function? on MSDN it says almost nothing:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh451231%28v=vs.85%29.aspx

As I've seen from the other issues about other games with the same problem, it's something windows-related.
I was thinking that maybe if it were possible to emulate this game on some other platform, like Linux, it might give some different informations. I've used CygWin a few times before, if there's any way to run the PPSSPP Linux version with it, I could try.

[unknownbrackets]

Hmm, not sure. ReadFromHardware is actually a PPSSPP function, not a Windows function (or at least, we don't use the Windows function.)

It means that the game, probably due to the results of a syscall or badly emulated CPU instruction, tried to access a memory address that is invalid. On the PSP, the game would crash if this happened. So it means something went wrong before that for it to use that address.

-[Unknown]

[ghost]

I see, it might be related to some ignored invalid access that happen before that point? in all these tests the invalid accesses were ignored, there were too many so I just disabled them.. xD but if that's the cause, I'll try checking them all.

[unknownbrackets]

How is this game looking lately? Still has issues?

-[Unknown]

[ghost]

I missed a lot of progress! a lot of stuff is fixed in the latest build v0.8.1 r63 b12604 (32 bits), like the opening videos (now they're working) and some graphic glitches^[*] (the black square that used to be in some fading scenes is no more, I can see the background now).

Played for a while ignoring the addresses, the debug window was really kicking though, but it didn't crash until I tried to save the game, it crashed while loading the available save slots, like it used to crash here: #1550 (comment)

Log saved here: http://limelinx.com/b9ink

The opening videos were muted but that's probably because I didn't try the new audio plug-in yet, there's a lot that I've to update... xD

I'm working on a project for a blog atm but one of these days I'm going to test everything like before, this summer I'll get a new hdd too, so I can finally set up a virtual machine and reinstall that crappy visual studio, microsoft really kills the motivation...

EDIT: installing the audio plug-in using PPSSPP was really easy, 100% working even in opening videos and it sounds great, music/voices/se aren't rusty anymore! that's amazing... I'm wanna cry, this emulator is progressing at light-speed!

[unknownbrackets]

Hmm this isn't good:

C++ runtime abort: terminate() called by the exception handling mechanism

I wonder what is causing that...

-[Unknown]

[unknownbrackets]

How does this game look these days?

-[Unknown]

[ghost]

I can't believe that I finally found the cause of that linker error.. it wasn't the incremental linking but just a conflict with multiple versions of cvtres.exe (.NET version is the one being used, VC++'s version was causing the conflict), I can start debugging once again :)

[ghost]

Today I tried to run a debug and noticed a visual glitch similar to something that before^[*] was fixed in a previous build:

The right side of the screen was flickering (that white/pink square is not supposed to be there), but that happens only when a 3d model (like the girl on left) is fading or appearing, in that moment it was appearing.

After playing for a few minutes, saved and loaded different times (no problems about that), during a transition from a scene to another, PPSSPPDebug.exe stopped and VC++ reported this:

Unhandled exception at 0x1275c649 in PPSSPPDebug.exe: 0xC0000005: Access violation reading location 0x339c7d50.

Screenshot of the frozen ppsspp window (couldn't click anything, not even the dropdown menus):

VC++ stack trace:
http://pastebin.com/raw.php?i=6VnWEBLz

Screenshots:
http://imgur.com/a/HhCH1#0

VC++ Output [Debug]:
http://pastebin.com/raw.php?i=hywNGBYP

This is last line from PPSSPP debug console:

52:00:424 CRI Server M E[KERNEL]: hle\scekernelthread.cpp:1492 800201bc=sceKernelReferThreadStatus(323, 0bf9c990): bad size 163980456

All 9999 lines from PPSSPP debug console:
1-3333 | 3334-6666 | 6667-9999

Everything above and more: @Mega

About the log, how do you use --log=mylogfile.txt in vc++ to force the full log generation, for ppsspp debug console? I could save only last 9999 lines copying them directly from the console window.

[thedax]

About the log, how do you use --log=mylogfile.txt in vc++ to force the full log generation, for ppsspp debug console? I could save only last 9999 lines copying them directly from the console window.

Right click the PPSSPPWindows project -> Properties -> expand Configuration Properties -> Debugging -> Enter the command-line args you want into Command Arguments. Then start debugging PPSSPP as usual.

[ghost]

I forgot to say that this time I didn't modify any settings nor files (linker, dx sdk or anything like that), so the build was clean, using the files as they were downloaded from github (time of commit 9c7e21c29c).
I've uploaded my ppsspp.ini to mega just now if it's needed and thanks @thedax 👍

[unknownbrackets]

Hmm. Feels like stack corruption to me but I'm not sure.

I recommend disabling "fast memory" in settings. It will prevent crashes from things like that (it will still log.) The game might go on. But we should find why it's doing that.

-[Unknown]

[daniel229]

Invalid address freezing have been fixed by @unknownbrackets #5368 ,graphic glitch is still happening.

[unknownbrackets]

That's good. The graphic glitch is the black columns, right? Could be a block transfer/memory copy issue.

-[Unknown]

[daniel229]

It is the extra picture come out.
Here's the video show the problem.
http://www.youtube.com/watch?v=EmUVUwuI-Ns

[unknownbrackets]

Ah, yeah, that definitely looks like either an FBO being kept alive or memset/memcpy/block transfer/dma type stuff.

-[Unknown]

[unknownbrackets]

Does this do any better in the latest git buids with simulate block transfer and etc.?

-[Unknown]

[daniel229]

Graphics has not been improved yet with the latest build v0.9.8-1614-g459e244

[unknownbrackets]

@daniel229 I think that last change fixed this, is that right? Is there anything left?

-[Unknown]

[daniel229]

Yes,fixed,but that effect may looks like at a low resolution.

[unknownbrackets]

Well, it's making copies... without making an emulator for this game specifically or patching this game, it's probably not avoidable. I mean, we could track that it's a copy, but we'd have to track all memory writes, and it'd be very slow.

-[Unknown]