[Regression] VSH/XMB no longer works (#15496)

[GoonyBaloney]

Quick summary

Trying to boot VSH/XMB gives you an error that says "This PS3 application has likely crashed, you can close it." and stayed on a black screen.

Details

It worked fine on v0.0.31-16381-b38ce945 (commit b38ce945) and earlier. but since v0.0.31-16387-e2402b1c (commit e2402b1c), when trying to boot VSH/XMB, a hint pops up that says "This PS3 application has likely crashed, you can close it." and the PPU compilation hint stays on indefinitely. It'll stay on a black screen until the emulation is stopped.

Build with regression

v0.0.31-16387-e2402b1c

Attach two log files

before-regression.log.gz after-regression.log.gz

Attach capture files for visual issues

No response

System configuration

Windows 10 22H2 i7-7700K GTX 1060 6GB (546.17)

Other details

I did every troubleshooting method beforehand but it still won't boot in the latest version.

[st12q]

Confirming, after updating RPCS3, XMB no longer works. Firmware version: 4.91 F {PPU[0x1000000] Thread (main_thread) [0x0047aff8]} SIG: Thread terminated due to fatal error: Null function: sys_time_get_system_time (in file D:\a\1\s\Utilities\JITLLVM.cpp:59[:22], in function null) (error=0x7e) - this is what it's writes in log in RPCS3 after trying boot into XMB. It doesn't crash with Interpreter (static) on PPU. Tried removing PPU, SPU and disk caches and creating LLVM caches from RPCS3, didn't helped. System configuration: Windows 11 23H2 i5 12400 RTX 4060 (552.22, Studio) Log: RPCS3-XMB-Issue.log.gz

[AniLeo]

Issue seems to be because sys_time_get_system_time is not declared as a NULL_FUNC syscall anymore @capriots from #15496

[capriots]

Clearing PPU cache should solve it

[GoonyBaloney]

Clearing PPU cache should solve it

I did do that multiple times but the issue still persisted

[AniLeo]

From what I saw, it's because you unregistered a valid syscall, I pushed a fix on #15530

[capriots]

From a quick glance it doesn't seem like VSH is using that other syscall. The problem is that I changed the name. @GoonyBaloney can you try deleting all the folders starting with "ppu-" in the cache folder and then start VSH again?

[AniLeo]

@capriots you're right, a full clean of all the caches does work. I think my PR incorrectly fixes the issue by restoring the previous functionality if you have an old cache only (the 0x92 syscall calling 0x95 instead of the correct one).

Do you have any ideas on how to solve this without bumping the PPU cache version?

Also it doesn't help that we're missing a clean VSH PPU cache option in the UI, so I opened issue #15531

[capriots]

I think some precompiled library still linked to that name

[GoonyBaloney]

From a quick glance it doesn't seem like VSH is using that other syscall. The problem is that I changed the name. @GoonyBaloney can you try deleting all the folders starting with "ppu-" in the cache folder and then start VSH again?

Just done it with v0.0.31-16390, it fixed the issue. Don't know if it'll come back again but glad to know about that. Thanks. ✌