God of War crashes just after boot on Android (Adreno 740)

[WizzardSK]

Moved from WizzardSK/pcee2-libretro#30, where it was filed against the wrong core. Reported by @Bernstein94; the log there loads pcsx2_libretro_android.so and writes saves under RetroArch/saves/LRPS2/, so it belongs here.

Symptom

God of War (USA) boots and then crashes shortly after. The reporter also mentions GTA Vice City booting with uneven audio, which may or may not be the same underlying cause.

Environment

• RetroArch 1.22.2, Android 16, arm64-v8a, sideload
• Xiaomi 23113RKC6C, Adreno 740
• Vulkan display driver, OpenSL audio
• God of War (USA), SCUS-97399, ELF CRC D6385328
• Fastmem enabled; GameDB applied alignSprite, roundSprite and autoFlush

What the log shows

retroarch.log from the original report.

Nothing about the crash itself. The log stops mid-sentence in the middle of repeated

microVU1: 2 cycle stall on branch instruction [03b0]
microVU1: 1 cycle stall on branch instruction [0538]
microVU1: 3 cycle stall on branch instruction [0588]

which is what a hard native crash looks like from RetroArch’s side: RetroArch cannot log a signal that kills the process, and until #158 the core installed no reporter of its own — the only sigaction in the tree is the fastmem page fault filter. So there is no fault address and no program counter to work from yet.

What can be said is that the last thing the core did before dying was microVU1 compiling VU1 programs.

Next steps

Waiting on the reporter for adb logcat or a tombstone, and for the result of three core option changes, each of which rules something in or out:

• MTVU off. On arm64 this defaults to on whenever the native VU1 recompiler drives VU1. First suspect, and the most likely explanation for the Vice City audio too.
• VU1 softfloat on. Takes the VU1 recompiler out of the picture; if the game then boots, this is VU1 codegen.
• EE = Interpreter. Removes the EE recompiler entirely; a crash that survives it is not EE codegen.

#158 adds a crash handler that will answer the main question directly on the next report — whether the program counter was inside the core’s own text or inside generated code.

[Bernstein94]

As I'm running android, i can't use adb logcat without root permission; and for tombstone data, also inaccessible. Instead, i tried to run with MTVU off, VU1 softfloat on, EE = Interpreter as suggested. But the crash still happenin. Adding a log.

retroarch.log

[WizzardSK]

Thanks — that it still crashes with all three off is the most useful thing you could have sent, because it points away from the recompilers entirely.

Two of the three are confirmed applied from your log: VU1 soft float: running on the exact interpreter and Fastmem: DISABLED, the latter being what EE = Interpreter does. So VU1 and EE codegen are out.

MTVU I cannot confirm either way, and that is a gap in the core rather than anything you did. The MTVU enabled line comes from the code that sets the platform default; the value actually applied from pcsx2_mtvu is never logged, so the log cannot tell us what it ended up as. Worth fixing separately.

What matters more is where your log stops. Not mid-emulation this time — right after this:

SET_SYSTEM_AV_INFO: 640x448, Aspect: 1.3333, FPS: 59.9401, Sample rate: 48000
... video and audio drivers reinitialised ...
SET_SYSTEM_AV_INFO: 640x448, Aspect: 1.3333, FPS: 59.9401, Sample rate: 48000
... video and audio drivers reinitialised again ...

Two announcements with identical values, each making RetroArch tear down and rebuild its whole video driver — which on the Vulkan path means destroying and renegotiating the context. update_av_info() sent those unconditionally, without comparing against what had last gone out and without waiting for the GS thread, so the rebuild could land on a thread still submitting to the shared Vulkan queue.

PCEE2 had exactly this and was fixed in adf456e28d. #160 brings both halves of that fix over: announce only on a real timing change (geometry goes through SET_GEOMETRY, which needs no reinit), and drain the GS thread before an announcement that does go out.

Being straight about how strong this is: it is a hypothesis your log supports, not a confirmed fix. Nothing in the log says what the crash actually was, because the core has no crash reporter yet — that is #158, which would print the faulting thread and whether the program counter was in generated code or the core’s own. Without it, and without logcat, we are reading tea leaves. What is certain is that the frontend was rebuilding its video driver for no reason at the moment everything stopped.

If you would like to test #160 before it is merged, say so and I will get you a build.

[Bernstein94]

Somehow managed to get this using shizuku+logfox.
See if it helps

crash-com-retroarch-aarch64-29_08-01-07-21_682.log