Retroarch crashes under Swaywm

[kzwicker]

Description

Crashes with Sway window manager when switching workspaces such that Retroarch is the first program in focus, or when toggling Retroarch to be a floating window instead of a tiling window.

Expected behavior

Should remain running like any other application.

Actual behavior

Closes instantly and somewhat gracefully with the following log messages (verbose):

[INFO] [Config]: Saved new config to "/home/czwicker/.config/retroarch/retroarch.cfg".
[INFO] [PulseAudio]: Unpausing.
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [PulseAudio]: Pausing.
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..

Steps to reproduce the bug

First option:

1. Open Retroarch
2. Be sure to hover mouse over Retroarch tile
3. Switch to another workspace
4. Switch back to workspace with Retroarch

Second option:

1. Open Retroarch
2. Try to switch Retroarch to a floating window (win+shift+space by default)

Bisect Results

1.18.0 does not have this problem. Was able to replicate the issue with a fresh Arch install in a vm using the archinstall script and choosing a Sway environment. Does not occur in i3 or Plasma under Arch. Does not occur in the Sway spin of Fedora, perhaps because it is on 1.19.0.

Version/Commit

• RetroArch: 1.19.1

Environment information

• OS: Arch Linux
• WM: Sway
• Compiler: GCC

[viachaslavic]

Does this also happen when building from the master branch? Could you please provide a backtrace?

[Limero]

I have the same issue on Fedora 41 Sway Atomic using the RetroArch flatpak from Flathub (v1.19.1).

I tried building both latest master and 1.19.1 from source and can't replicate the issue, I also tried the pre-built 1.19.1 and nightly (2024-11-09) appimage from the buildbot and the issue doesn't seem to happen there either

[Limero]

Running gdb in the RetroArch flatpak and triggering the bug shows that the process didn't crash, but did "exit normally", so no backtrace.

flatpak run --command=sh --devel --filesystem=$(pwd) org.libretro.RetroArch

Starting program: /app/bin/retroarch 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe4a006c0 (LWP 26)]
[New Thread 0x7fffe36006c0 (LWP 27)]
[New Thread 0x7fffe2c006c0 (LWP 28)]
[New Thread 0x7fffe22006c0 (LWP 29)]
[New Thread 0x7fffe18006c0 (LWP 30)]
[New Thread 0x7fffe0e006c0 (LWP 31)]
[New Thread 0x7fffdbe006c0 (LWP 32)]
[New Thread 0x7fffdb4006c0 (LWP 33)]
[New Thread 0x7fffda6006c0 (LWP 34)]
[Thread 0x7fffdb4006c0 (LWP 33) exited]
[Thread 0x7fffdbe006c0 (LWP 32) exited]
[Thread 0x7fffe0e006c0 (LWP 31) exited]
[Thread 0x7fffe18006c0 (LWP 30) exited]
[Thread 0x7fffda6006c0 (LWP 34) exited]
[Thread 0x7fffe4a006c0 (LWP 26) exited]
[Thread 0x7fffe22006c0 (LWP 29) exited]
[Thread 0x7fffe36006c0 (LWP 27) exited]
[Thread 0x7fffe4b4ee00 (LWP 23) exited]
[Thread 0x7fffe2c006c0 (LWP 28) exited]
[New process 23]
[Inferior 1 (process 23) exited normally]
(gdb) bt
No stack.

[viachaslavic]

Bisect results: fixed in 3ee3f2ae .

The fixed version is already available in nightly builds, or wait for a new release.

[viachaslavic]

@Limero please check on version 1.20.0

[Limero]

Using 1.20.0 through Flatpak, I'm no longer able to replicate the issue :tada:

[kzwicker]

1.20.0 in pacman has solved the issue as well!