[Bug]: Linux aarch64 — JITARM64 together with the main CPU thread hangs the frontend after a few seconds

[WizzardSK]

Summary

On a native Linux aarch64 build of the core, the default option combination dolphin_cpu_core = 4 (JITARM64) + dolphin_main_cpu_thread = enabled runs for roughly ten seconds and then the frontend stops producing frames entirely: RetroArch's main loop no longer answers network commands (SCREENSHOT, QUIT) and the process has to be killed. CPU usage drops to ~13%, nothing is logged by the core or by RetroArch after the hang.

Changing either of the two options makes it run indefinitely, so it looks like a race between the JITARM64 CPU thread and the video/main thread rather than a plain JIT miscompile:

dolphin_cpu_core	dolphin_main_cpu_thread	result
4 (JITARM64)	enabled	boots, ~55 FPS, hangs between frame 600 and 1500
4 (JITARM64)	disabled	3000 frames in 60 s, ~60 FPS, no hang
5 (Cached Interpreter)	enabled	runs, ~16.7 FPS, no hang

Environment

• postmarketOS aarch64, Snapdragon 670 / Adreno 618 (Chromebook), 4 GB RAM
• RetroArch 1.22.2 (Flatpak), video driver gl (Mesa freedreno) and vulkan (Turnip) — both hang identically
• Core built from c6b8691 (plus only the aarch64 CI job from ci: add Linux aarch64 libretro build #458), CMake -DLIBRETRO=ON, GCC 15, LTO off
• Game: Mario Kart: Double Dash!! (USA), booted from ISO

Reproduction

printf 'dolphin_cpu_core = "4"\ndolphin_main_cpu_thread = "enabled"\n' \
    > .../config/dolphin-emu/dolphin-emu.opt
retroarch --max-frames=1500 --max-frames-ss --max-frames-ss-path=/tmp/shot.png \
    -L dolphin_libretro.so "Mario Kart - Double Dash!! (USA).iso"

• --max-frames=600 finishes in 19 s and writes a correct screenshot of the intro at 55 FPS.
• --max-frames=1500 never finishes (killed after 300 s, no screenshot).
• With dolphin_main_cpu_thread = "disabled", --max-frames=3000 finishes in 60 s.
• Reproduced on every attempt (5/5 across two sessions), with both video drivers.

Notes

The hang is not at startup — the intro renders at full speed first, and the frontend is fully responsive during that time. There is no log output at the moment it stops (verbose RetroArch log ends with the normal AV-info/audio-driver lines).

The workaround (dolphin_main_cpu_thread = disabled) costs no performance here — 60 FPS in the intro either way — but the hanging combination is what a user gets by default on aarch64, so the core looks broken out of the box on this platform.

I'm happy to run further experiments on the device (extra logging, thread backtraces, specific option combinations) if that helps narrow it down.

[cscd98]

Please provide a log.

[WizzardSK]

Sure — full verbose logs plus gdb thread backtraces of the hung process:
https://gist.github.com/WizzardSK/21d5b61e1c761f68c2ba33254471938d

• dolphin_log_hang.log — log_verbosity/libretro_log_level=0, dolphin_cpu_core=4 + dolphin_main_cpu_thread=enabled, --max-frames=1800: killed after 240 s, never reaches 1800 frames.
• dolphin_log_working.log — same command with dolphin_main_cpu_thread=disabled: 1800 frames in 43 s, exits normally.
• dolphin_backtrace.txt — thread apply all bt, taken 75 s into a hung run.

The log itself ends right after boot with nothing unusual (last core line is Core/Boot/Boot.cpp:555 N[BOOT]: Booting from disc: …), which is why the backtrace is the interesting part:

Frontend main thread — stuck inside retro_run():

Thread 1 (LWP 3) "retroarch":
#3  pthread_cond_clockwait () from libc.so.6
#4  Fifo::FifoManager::RunGpuLoop () from dolphin_libretro.so
#5  retro_run () from dolphin_libretro.so

The CPU thread — parked in the CPU state wait, not executing anything:

Thread 6 (LWP 36) "CPU thread":
#3  pthread_cond_wait () from libc.so.6
#4  std::condition_variable::wait(std::unique_lock<std::mutex>&) from libstdc++.so.6
#5  CPU::CPUManager::Run () from dolphin_libretro.so
#6  Core::CpuThread (Core::System&, …) from dolphin_libretro.so
#7  Core::EmuThread (Core::System&, …) from dolphin_libretro.so

So the GPU loop that retro_run() runs on the frontend thread is waiting for FIFO work, while the CPU thread is sitting in CPUManager::Run()'s condition variable, i.e. it is not in the running state and nobody wakes it back up. Everything else (DVD thread, memcard flush, savestate worker, asset loaders) is idle in its normal wait.

It is not a startup problem: with this configuration the game boots and renders the intro at ~55 FPS, --max-frames=600 completes in 19 s and writes a correct screenshot; it dies somewhere between frame 600 and 1500. After that RetroArch's main loop is gone, so it stops answering network commands too.

Environment: postmarketOS aarch64 (Snapdragon 670 / Adreno 618), RetroArch 1.22.2 flatpak, core built from c6b8691 with GCC 15, LTO off, Mario Kart: Double Dash!! (USA) from ISO. Reproduced on every attempt, with both the gl (freedreno) and vulkan (Turnip) drivers.

Happy to run anything else on the device — extra logging, a debug build, different games, or a backtrace at a specific point.