Ratchet & Clank:Size Matters - Crash/Freeze on Ad-Hoc - 1.10.1

[ghost]

Hi,it is me again,i encountered issue with Ad-Hoc option of game Ratchet & Clank:Size Matters.When i enter Ad-Hoc menu with both devices,running latest version of course,i can't create Profiles for both devices,stating Password needed to enter,but this is Ad-Hoc and there is no password frame for entering it.If i manage to do so,game crashes when hosts enters the game,interestingly enough,i tried version 0.9.7 and everything worked fine.If possible,i could be happy if you managed to fix this problem for next update.

TIA

[ghost]

I dont think this will be fixed anytime soon. You could use JPCSP or the old PPSSPP for now.

[ghost]

Thank you for feedback,i appreciate it. I don't want to sound mean,but i will wait for developer's answer and rant about this

[hrydgard]

PPSSPP's AdHoc support is still very experimental and rough. It seems as soon as someone fixes one game, another game breaks so it's very hard to keep everything working. The AdHoc APIs are extremely complex and fragile and indeed not enough effort has been spent on this so far for it to be reliable...

It's just way harder than other parts of the PSP to emulate and very difficult to work on due to the need to use multiple instances for debugging. I know this is excuses, but it's what it is.

[ghost]

PPSSPP's AdHoc support is still very experimental and rough. It seems as soon as someone fixes one game, another game breaks so it's very hard to keep everything working. The AdHoc APIs are extremely complex and fragile and indeed not enough effort has been spent on this so far for it to be reliable...

It's just way harder than other parts of the PSP to emulate and very difficult to work on due to the need to use multiple instances for debugging. I know this is excuses, but it's what it is.

Well,i see,it is complicated a lot,and it must be hard to work on the code otherwise than Ad-Hoc itself,it is fine and i understand,i will silently wait in future for the fix.Thanks

[adenovan]

PPSSPP code style on C++ is beauty and dang when i jump into adhoc code im looking a spagethi , it is just an excuse but it's what it is too.

need to solve #10832 before jumping into this issues and clear some confusion on the mips call and the adhoc control handler it is the most biggest change from 0.9.7.

rewrite the BSD socket implementation and C code into PPSSPP C++ code style need much energy too , emulator scope is broad especially looking for host machine supported on PPSSPP compability is not an easy thing to maintain as the host machine can restrict some of low level networking call beside of that autotest TDD on adhoc is not finisihed too, some manual work needed as its often crash your PSP WLAN DRIVER.

[ghost]

@adenovan Hi,me again.Since ANR2ME is retiring from PPSSPP,what is your next to-do list on PPSSPP branch?This is little off-topic,but it seems Ad-Hoc here is the major problem.

[adenovan]

My to do list right now

• create homebrew for adhoc test environment with real console
• redocument and dig error info on scenetadhoc , scenetadhocmatching , scenetadhocctl , scenet sony implementation.
• build new network protocol or use existing lib on networking as transport layer (adhoc tunnel experiment) for internet play , need edge to edge relay server like whatsapp for this its still uknown pretty fragile.
• improve compability and ease of use in local network play between sony console and the emulator

[ghost]

That is really big list,and seems it is very complicated to completely rewrite Ad-Hoc functions.I wish you best luck on it.

[anr2me]

My to do list right now

* create homebrew for adhoc test environment with real console

* redocument and dig error info on scenetadhoc , scenetadhocmatching , scenetadhocctl , scenet sony implementation.

* build new network protocol or use existing lib on networking as transport layer (adhoc tunnel experiment) for internet play , need edge to edge relay server like whatsapp for this its still uknown pretty fragile.

* improve compability and ease of use in local network
  play between sony console and the emulator

Don't forget to implement the blocking-socket simulation using non-blocking socket + hleDelayResult :) this should helped reducing stutter (including audio stutter perhaps) and performance degradation during multiplayer a lot :D

[ghost]

The game wont crash when using the european version of the game - it will just freeze instead. It's interesting that it worked on previous versions of PPSSPP though.

[anr2me]

The game wont crash when using the european version of the game - it will just freeze instead. It's interesting that it worked on previous versions of PPSSPP though.

On the EU version, i think it started to freeze (at least the image on screen) when these errors appearing: PS: Software renderer will crash instead of freezing

Also regarding the issue with profile, @zakilj3 said it only happened when he speedup the game, so may be it have something to do with the timing?

[zakilj3]

I think its timing too as when you create a profile in ratchet & clank size matter, it actually create a specific savefile for it and when you open the multiplayer it load the savefile for multiplayer. So when you speed up the game, I guess it doesn't load properly the save

[ghost]

Also note this is another game that works (multiple instances) on JPCSP and you dont even need the prx files there. It works fine and wont freeze or crash but I only managed to do it with multiple instances last time I tried.

[anr2me]

Based on the logs i posted, it's clearly GPU issue LOL, need someone to check those vertex and illegal BJUMP errors first

[hrydgard]

Well, if you get that kind of logs, memory got corrupted somewhere and caused the game to run garbage as a display list. No way to recover from there.. The bug that caused the corruption needs fixing and that can be hard to find.

[Double-0-seven7]

So its adhoc related or not? Should another issue be opened not related to this?

[hrydgard]

If it only blows up when using the network stuff, it might very well be the cause, either due to a bug directly in networking functions, or some unrelated timing bug, similar to the very obscure one we recently fixed in Crazy Taxi (an example of the kind of bug, not an example of network related)... Hard to say.

[anr2me]

If it only blows up when using the network stuff, it might very well be the cause, either due to a bug directly in networking functions, or some unrelated timing bug, similar to the very obscure one we recently fixed in Crazy Taxi (an example of the kind of bug, not an example of network related)... Hard to say.

Actually, it also happened once before using any networking API, right after choosing "Multiplayer Mode" from start menu there will be 3D animation of a rocket flying to a planet, and during this animation it suddenly crashed, while network are initialized on the next menu (Adhoc and Infrastructure selection) after this animation finished.

But on the US version these crash is random, just like the issue of Profile/savedata(issue without speedup), but if it were able to successfully start the multiplayer match and enter the field it won't crash or freeze like what happen on EU version.

PS: The issue of Profile in the US version can be annoying because it happened often and when it happened we can't progress any further without deleting the savedata first, while the EU version didn't have this issue. So may be we can solve this Profile/savedata first?

[anr2me]

@EX-e-LD you probably need to track down the last version that didn't crash since 0.9.7 you can jump forth at larger interval and jump back halfway if it was broken until you can close the gap.

You can download older version from https://github.com/hrydgard/ppsspp/tags?after=v1.3

[adenovan]

Well, if you get that kind of logs, memory got corrupted somewhere and caused the game to run garbage as a display list. No way to recover from there.. The bug that caused the corruption needs fixing and that can be hard to find.

pretty sure its get corrupted in the network loop , on real console when i do some test on adhoc with joining some game throught their networking beacon to do some test tdd as client many of the display got broken in the host when we just idling not replying something they game expect is always there.

That some sort of packet is still far deep down below , corrupting the host display is so simple , play an adhoc game that make the wireless adhoc turn green.

join the control room with homebrew with same name without do some kind of pdp or ptp broadcasf , host will just keep going without any crash but display is screwed everywhere.

[ghost]

Well there is also a graphics corruption issue when going to the adhoc lobby on Kingdom Hearts : https://media.discordapp.net/attachments/509529410123333632/756492385218723860/Recoded.png?width=818&height=630 Dunno if its related to Ratchet & Clank but I decided to share it here anyway. It's random and not that harmless bug there because after you start a game the graphics become ok.

[ghost]

Hi.Me again.Long time no see.I'm in bit of a hurry and i won't be able to test games for really while,i have schedule that's not so easy to follow and GitHub or video-games won't fit for sure.I'm sorry,but i think i will maybe be able to do so when nearest holidays come,until that i won't be active.I'm sorry for any inconvenience i caused.May i ask you to just report latest progress you will do.

TIA

[ghost]

Look like I got the game to work without crashing but the 2nd player is stuck under the map for some reason. Here are some pictures: 1st player:

2nd player: This only works with the european version for now. If you want to get to this state you need to choose the Death Match mode and choose Danger Valley as the map. Capture The Flag mode also works with the map but you will get the same result.

[anr2me]

Looks like the issue with Ratchet & Clank Size Matter is related to Dynarec/JIT. If i use Interpreter the logs are no longer spammed with Bad vertex address errors and the game runs without issue (other than the slow performance with interpreter)

Btw, what is the difference between Interpreter with IR Interpreter?

Edit: Looks like disabling the VFPU_VEC on the JIT is sufficient.

[anr2me]

Looks like i was just lucky not to get crashed just by disabling VFPU_VEC because i was using Debug build when testing it (to findout why it crashed, which apparently a crash on JIT), probably because Debug build runs slower compared to Release build, just like how interpreter runs slower than JIT.

When i tested again using Release build, it still crashed even when i've disabled all FPU/VFPU related JIT

Edit: Hmm.. it's really strange, It always works when i use Interpreter on Debug build, but i need to load it from savastate due to very slow boot time.

[ghost]

I already tested this with interperter and the software renderer and it didnt work so... But maybe the issue is closer then you think.

[anr2me]

Ah.. looks like what fixed it was because i load it from savestate, tested on Release build with Interpreter, IR Interpreter, and Dynarec were all successful.

I create that savestate because this game were having annoying issue when loading profiles from savedata, where i need to reboot the game many times before i can successfully get the profile to load without weird issue (ie. after creating new profile it can't be loaded), so when i managed to get the profile working properly i decide to create a savestate to saves me from this annoying profile issue. May be those profiles issue sometimes corrupting the data?

[ghost]

Right using a save state after the loading moment of the profiles fixes the issue.... So it's not ad-hoc related.. (?)

[anr2me]

Just now i tried to create a new savestate. 1). Run the game on 1st instance, until it loads multiplayer profile successfully. 2). Create savestate during the "Adhoc/Infrastructure" menu. 3). End the game on 1st instance and relaunce the game + load the save state. 4). Launch the game on 2nd instance and load the same savestate with 1st instance. After both players joined and the mission started, Player1 (1st instance) crashed while the 2nd player were able to enter the game successfully (without any weird error message in the log)

Edit: I tried again after closing both PPSSPP and load the same savestate on both instance and both of them were able to enter the game successfully. May be i need to closedown PPSSPP first after creating the savestate in order to make it works... Exiting to Menu wasn't enough.

[ghost]

I can't get localhost to work with using a savestate. It won't show the other player on the 2nd instance....

[anr2me]

I can't get localhost to work with using a savestate. It won't show the other player on the 2nd instance....

You are using the latest build from https://buildbot.orphis.net/ppsspp/ right? Don't use my old test build, it doesn't have the commits that was related to shaders/GPU.

Create the savestate after profile were loaded during this screen (no sceNet function is being used yet at this point) And don't forget to close down PPSSPP after creating the savestate, because it makes a different, while Exit to Menu won't makes a different.

[ghost]

Yeah cool. I wonder if its a similar issue as the one @shenweip fixed with the kernel thread on Resistance.

[anr2me]

Not sure, i don't even know why i need to close down PPSSPP first in order to make it work... may be the corruption resides within PPSSPP's memory it self instead of the emulated PSP's memory?

[ghost]

Looks like it wont work on the European version again lol. I wonder why its like that you think there wont be much difference.

[anr2me]

I tested on both US and EU version the savestate tricks worked fine. Try to recreate the savestate again with a fresh instance of PPSSPP (just in case the corruption happened within PPSSPP itself) if it still failed (just in case the profile were already corrupted when you created the savestate), and don't forget to closedown PPSSPP after creating the savestate, because it may not work if you just choose Exit to Menu.

PS: i only tested this on Windows 32-bit version tho, not sure if 64bit will be different or not.

[anr2me]

Hmm.. looks like creating the savestate before loading the profile also works, i tried to save it during the rocket/space shuttle animation, and it works. But creating the savestate while in Main Menu doesn't works... so may be the corruption occurred during that rocket animation.

[ghost]

Yeah AdamN I got it to work you just need to use the latest build I guess or something. Anyway I got a detailed log here with "Debug" i putted in places I thought might help find the problem. Here is it : https://pastebin.com/C6WkK1Ew I saw some red lines and yellow lines there regarding GPU related stuff I think. Here is another one with "Info" in every logging channel : https://pastebin.com/x6PZmJuz Someone of the red lines appear after the rocket launch finishes indeed.

[anr2me]

What happened after the rocket animation finished might not be an issue. But what happened before the savestate created is the one that have a high probability to cause the corruption,. So when you loaded the savestate from a fresh instance of PPSSPP it will bypass the code that was causing the corruption, and it need to be a fresh instance of PPSSPP to make sure it's memory isn't contaminated with corrupted data. The corruption seems to happen between the moment you choose Multiplayer menu and the middle of rocket animation.

PS: You need the latest automatic build probably because there have been a lot of commits related to GPU recently, and some of them might fixed some of the corruption, but some of them might still have the bug.

I tried to compare the 3D/GE/Display log near the vertex error between a successful gameplay and the error/crashing one, but since i'm not familiar with it i have no clue what's happening LOL

HOST (Error):
-------------
02:38:024 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:024 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:148 rcp level ma D[SCEGE]: HLE\sceGe.cpp:339 sceGeListEnQueue(addr=098a9400, stall=00000000, cbid=00000000, param=09fcd000)
02:38:148 rcp level ma D[G3D]: GPU\GPUCommon.cpp:1187 Starting DL execution at 098a9400 - stall = 00000000
02:38:149 rcp level ma D[SCEGE]: HLE\sceGe.cpp:348 35000038=sceGeListEnQueue(098a9400, 00000000, 0, 09fcd000[00000010])
02:38:149 rcp level ma D[SCEGE]: HLE\sceGe.cpp:393 sceGeDrawSync(mode=0)  (0=wait for completion, 1=peek)
02:38:161 rcp level ma D[SCENET]: HLE\sceNet.cpp:759 sceNetEtherNtostr(09fcd020, 09fcd0a0) at 09dc1bc4
02:38:440 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:472 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:549 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:615 rcp level ma D[SCEDISP]: HLE\sceDisplay.cpp:1055 0=sceDisplaySetFrameBuf(04000000, 512, 3, 0)
02:38:616 rcp level ma D[SCEGE]: HLE\sceGe.cpp:339 sceGeListEnQueue(addr=498ea480, stall=00000000, cbid=00000000, param=09fcd190)
02:38:616 rcp level ma D[G3D]: GPU\GPUCommon.cpp:1187 Starting DL execution at 098ea480 - stall = 00000000
02:38:616 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44110000 = 480x272
02:38:616 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04174000 V: 64x64, R: 480x272, S: 64x64, STR: 64, THR:1, Z:44000000 = 64x64
02:38:619 rcp level ma W[SCEGE]: Common\FramebufferManagerCommon.cpp:405 FBO using existing buffer as depthbuffer, 04174000/04000000 and 04000000/04110000
02:38:621 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:00000000 = 480x272
02:38:621 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:2027 Reading framebuffer to mem, fb_address = 04174000, ptr=0000016ABFB84000
02:38:633 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=1 COL=0 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
02:38:633 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 12, aligned to biggest 2
02:38:639 rcp level ma E[G3D]: GPU\GPUCommon.cpp:1583 Bad vertex address 048e0ea4!
02:38:639 rcp level ma E[G3D]: GPU\GPUCommon.cpp:1583 Bad vertex address 048e0ea4!

HOST (Success):
----------------
08:15:268 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
08:15:340 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
08:15:451 rcp level ma D[SCEDISP]: HLE\sceDisplay.cpp:1055 0=sceDisplaySetFrameBuf(04000000, 512, 3, 0)
08:15:452 rcp level ma D[SCEGE]: HLE\sceGe.cpp:339 sceGeListEnQueue(addr=498ea480, stall=00000000, cbid=00000000, param=09fcd190)
08:15:452 rcp level ma D[G3D]: GPU\GPUCommon.cpp:1187 Starting DL execution at 098ea480 - stall = 00000000
08:15:452 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44110000 = 480x272
08:15:453 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04174000 V: 64x64, R: 480x272, S: 64x64, STR: 64, THR:1, Z:44000000 = 64x64
08:15:456 rcp level ma W[SCEGE]: Common\FramebufferManagerCommon.cpp:405 FBO using existing buffer as depthbuffer, 04174000/04000000 and 04000000/04110000
08:15:459 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:0, Z:00000000 = 480x272
08:15:459 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:2027 Reading framebuffer to mem, fb_address = 04174000, ptr=000001F503624000
08:15:471 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=1 COL=0 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
08:15:471 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 12, aligned to biggest 2
08:15:529 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=2 COL=6 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
08:15:529 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 16, aligned to biggest 2
08:15:646 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=1 COL=0 POS=2 NRM=1 WT=1 NW=2 IDX=0 MC=1
08:15:646 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 14, aligned to biggest 2
08:15:798 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04154000 V: 480x272, R: 480x272, S: 241x137, STR: 256, THR:1, Z:00000000 = 256x272

=================================================================================================================================
CLIENT (Error):
------------
02:38:524 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:526 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
02:38:600 rcp level ma D[SCEDISP]: HLE\sceDisplay.cpp:1055 0=sceDisplaySetFrameBuf(04000000, 512, 3, 0)
02:38:600 rcp level ma D[SCEGE]: HLE\sceGe.cpp:339 sceGeListEnQueue(addr=498ea480, stall=00000000, cbid=00000000, param=09fcd190)
02:38:600 rcp level ma D[G3D]: GPU\GPUCommon.cpp:1187 Starting DL execution at 098ea480 - stall = 00000000
02:38:600 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44110000 = 480x272
02:38:611 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=1 COL=0 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
02:38:611 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 12, aligned to biggest 2
02:38:616 rcp level ma E[G3D]: GPU\GPUCommon.cpp:1583 Bad vertex address 048e0ea4!
02:38:617 rcp level ma E[G3D]: GPU\GPUCommon.cpp:1583 Bad vertex address 048e0ea4!

CLIENT (Success):
----------------
08:15:307 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
08:15:310 rcp level ma D[SCEGE]: HLE\sceGe.cpp:320 04000000 = sceGeEdramGetAddr
08:15:385 rcp level ma D[SCEDISP]: HLE\sceDisplay.cpp:1055 0=sceDisplaySetFrameBuf(04000000, 512, 3, 0)
08:15:385 rcp level ma D[SCEGE]: HLE\sceGe.cpp:339 sceGeListEnQueue(addr=498ea480, stall=00000000, cbid=00000000, param=09fcd190)
08:15:386 rcp level ma D[G3D]: GPU\GPUCommon.cpp:1187 Starting DL execution at 098ea480 - stall = 00000000
08:15:386 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04088000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:44110000 = 480x272
08:15:396 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=1 COL=0 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
08:15:396 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 12, aligned to biggest 2
08:15:455 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=2 COL=6 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
08:15:455 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 16, aligned to biggest 2
08:15:739 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=0 TC=2 COL=6 POS=2 NRM=1 WT=0 NW=1 IDX=0 MC=1
08:15:739 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 16, aligned to biggest 2
08:15:740 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04154000 V: 480x272, R: 480x272, S: 241x137, STR: 256, THR:1, Z:00000000 = 256x272
08:15:745 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1084 VTYPE: THRU=1 TC=2 COL=0 POS=2 NRM=0 WT=0 NW=1 IDX=0 MC=1
08:15:746 rcp level ma D[G3D]: Common\VertexDecoderCommon.cpp:1260 SVT : size = 10, aligned to biggest 2
08:15:780 rcp level ma D[G3D]: Common\FramebufferManagerCommon.cpp:197 Est: 04166000 V: 480x272, R: 480x272, S: 121x69, STR: 128, THR:1, Z:00000000 = 128x272

[ghost]

I checked latest stable 1.10.3 and it still works (alone tho lol). BUT if you use 1.10.3 and a late ppsspp build it won't work. For the workaround to work all people need the same PPSSPP version or something in that ballpark.

[ghost]

I wonder why the label is still "adhoc/networking" when it got nothing to do with it lol.

[anr2me]

The list.pc location on the first Bad vertex address error is 0x041d042c When not using savestate (bad vertex error due to invalid vaddr):

And this is the correct one (no error) when loaded from savestate:

The address where the bad VADDR located seems to be written right after the rocket animation finished, but not sure why the content is different between using savestate or not. *I'm not sure which part of the code is the one that wrote that address... was it the jal 0x09233858 ? which is *replacement: move a3, a0 (which seems to use Replace_memcpy_jak to copy the contents from [a1] into [a0]) ... i wonder why it's mentioning a3 LOL

PS: Savestate was created in the middle of the rocket animation, not long right after selecting Multiplayer Menu

[hrydgard]

You can try to disable that function replacement and see if it makes any difference?

[anr2me]

You can try to disable that function replacement and see if it makes any difference?

I tried to disable Replace_memcpy_jak but it doesn't makes any difference, so i guess it wasn't that.

The original code is really move a3, a0 it was the function at 0x09233858 is the one that copy [a1] into [a0], it's just that when using Replace_memcpy_jak i can't steps into the next opcode and returning from that function immediately, which causing the memory write breakpoint not to shows the exact opcode writing it.

[anr2me]

Hmm.. the code that writes the invalid VADDR (0x018E8834) into [0x041d0424] seems to be occurred right after finished loading when multiplayer mission is started Since t1 content is calculated from other register/memory it's probably hard to tracks down where the content came from :(

And this is the content of the memory when loaded from savestate: I guess the only obvious difference is the previous VADDR content at [0x041d0424] which is loaded into t2 and used to calculate t1 and stored back into [0x041d0424]

And the one that written the previous VADDR (0xFFEEDDCC) when not using savestate is this code: Hmm.. there is a file path nearby the source of 0xFFEEDDCC data.. might be coming from a file?

And this is the one with savestate:

[anr2me]

LOL if i reset the game and try again over and over the corruption is getting worse... Sometimes it's running out of DL ID before setting up multiplayer lobby (did the display list didn't get cleared when resetting emulation?)

rcp level ma E[G3D]: GPU\GPUCommon.cpp:728 No DL ID available to enqueue

Sometimes getting this when the corruption is getting worse after several attempts:

[aliaspider]

did you try disabling fastmem ?

[anr2me]

did you try disabling fastmem ?

yes, i always disable fastmem when debugging

Anyway, i think i found some clue, the one that writes the memory (at 0x097D59BC) with different content between with/without savestate is this code: Could the corruption caused by sceIoReadAsync ?

And this is the argument at the entry of sceIoReadAsync: PS: The breakpoint at 0x09156748 only triggered when multiplayer mission being started (probably during loading scene)

Edit1: i tried to compare the content of memory [0x097D59BC] which is used by VADDR, right after sceIoReadAsync returned but both with & without savestate are having the same content.... or should i waited until the I/O really read it before comparing? since it's Async read... not sure how do i waited for async to be completed within PPSSPP debugger LOL

Edit2: The content of [0x097D59BC] changed with the faulty one after the 3rd occurrence of the breakpoint (so the 2nd sceIoReadAsync was the culprit... or may be the Async of the first occurrence completed after the 2nd initiated?)

This is the argument of the 2nd occurrence:

PS: This was tested on EU version where i loaded the savestate during language selection when using savestate.

[anr2me]

This is SCEIO Debug Logs without savestate:

This is SCEIO Debug Logs with savestate: Both SCEIO seems to be normal...

It was something else that wrote 0xFFEEDDCC to memory [0x097D59BC] which was taken from [0x097D4174]

If i put breakpoint on memory [0x097D4174] write, it will break near the sceIoReadAsync again... what the heck is going on with this loop LOL But this time the content (0xFFEEDDCC) that was written into [0x097D4174] were taken from [0x09850760]

Putting Memory Write breakpoint at [0x09850760] causing it to break at this strange location... none of the thread seems to be writing to that address :( The issue should be started within the rocket animation before savestate were created, which makes loading the savestate bypass the problematic code, but i can't find any breakpoints that got triggered there :(

[anr2me]

I tried to create Data Breakpoint on VS2019 by using the pointer returned from Memory::GetPointer(0x09850760) but it break into assembly instead of source code :( no callstack with source code either

[anr2me]

Looks like it really was sceIoReadAsync that wrote 0xFFEEDDCC into [0x09850760]

I ended testing it by adding this code inside sceIoReadAsync and IoAsyncFinish

if (params.std.addr <= 0x09850760 && 0x09850760 < params.std.addr + params.std.size) {
    WARN_LOG(SCEIO, "AsyncReading into [0x09850760]: %08x", Memory::Read_U32(0x09850760));
}

But when using savestate it also wrote 0xffeeddcc LOL this is confusing