accessibility causes retroarch to freeze, not announcing it's UI and must be killed with pkill in order to be closed.

[kendell-clark]

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

IN retroarch version 1.22, in fedora 43, retroarch seems to have a bug where, once accessibility is enabled retroarch will no longer read it's ui, and in fact must be killed with something like pkill in order to close. Steps to reproduc. Open retroarch, enable retroarch's accessibility support. It will initially read and navigate the ui, but once you save configuration and close, the bug kicks in and further starts of retroarch will no longer navigate the UI. This happens whether orca, the screen reader, is on or off, since retroarch uses espeak directly. The expected behavior is that retroarch should read it's ui and not freeze, requiring to be killed manually before it will close, but the actual behavior appears to be an application wide freeze of some sort, requiring pkill -9 or similar to kill the process, at which time retroarch closes and your normal linux applications resume functioning normally as they did before retroarch was opened

Expected behavior

No response

Steps to reproduce the bug

first, start retroarch. Then enable retroarch's accessibility support. You will initially be able to navigate retroarch's UI just fine, but upon saving and closing retroarch, the bug kicks in and subsequent starts will no longer read the UI and the app appears to freeze solid, requiring killing before it will close. I also tried retroarch inside a distrobox arch container to verify it was not a fedora specific issue and the same thing occured there, verifying it is a retroarch specific issue.

Version/Commit

1.22.0

Bisect Results

No response

Present in the nightly version

I don't know

Platform & operating system

fedora 43, 64 bit

Affected Cores

all cores

Environment information

No response

Relevant log output

[kendell-clark]

just installed retroarch from git in my distrobox arch container and the issue still occurs. only this time I couldn't get accessibility enabled so I suspect the bug triggers as soon as retroarch is launched but I can't see well enough to know for sure. This is still on fedora 43, on an arch distrobox, I don't have access to retroarch nightly on fedora, only inside the distrobox arch container

[kendell-clark]

Observation: On a system with 4 GB RAM and 4 CPU cores, building retroarch-git / nightly with the default PKGBUILD triggers heavy swap usage (~1.1 GB), which significantly slows the build. Linux remains functional, but compilation is memory-constrained.

Details:

System: 4 GB RAM soldered, 4-core CPU, Fedora/Arch derivative

Build method: yay -S --noconfirm retroarch-git (default PKGBUILD)

Cause: makepkg defaults to -j$(nproc) (4 parallel jobs), exceeding available RAM.

Suggested mitigation: Limit parallel jobs for low-RAM systems using: export MAKEFLAGS="-j2 -l2" This drastically reduces swap usage while building. Consider updating build instructions or PKGBUILD defaults for low-memory systems to avoid excessive swapping.

[gouchi]

Hi,

Thank you for the report. Can you provide some log ?

To check if this PR could help to fix your issue.

Also you can get some nightly build from the buildbot, if needed.