RDM Linux 2026.3.1.1 Flatpak crashes when closing an active SSH session; also observed while idle

RDM Linux 2026.3.1.1 Flatpak crashes when closing an active SSH session; also observed while idle

avatar

Hello Devolutions Support,

Remote Desktop Manager for Linux terminates with SIGSEGV when I close an active SSH session. I have also observed a crash while leaving RDM running without interaction. Two captured crashes have the same native stack signature in g_object_remove_toggle_ref. The session-closing crash also occurred with X11 explicitly forced and the Wayland socket disabled for RDM.

Impact
The whole RDM process exits, interrupting my remote-session workflow.

Environment
- RDM version: 2026.3.1.1, x86_64
- Installation: system-wide Flatpak, origin "devolutions", branch "current"
- App ID: com.devolutions.remotedesktopmanager
- App ref: app/com.devolutions.remotedesktopmanager/x86_64/current
- App commit: 6a30b972e332f8fb3b5f4f073da55ebbc1ffe85d2e26aa6ae973340b21f78235
- App build date: 2026-10-02 22:02:45 UTC
- Desktop: KDE; session type: Wayland
- Runtime: org.gnome.Platform/x86_64/49, origin "flathub", system installation
- Runtime commit: 2bb946ea4ebb050f6a32f90e979feb975b08280d1ff1aac881dec3d1361ad84d
- Runtime build subject: Build of the GNOME Runtime from: 49.10-1-g75d7cf116
- Runtime build date: 2026-10-03 06:00:39 UTC
- libgobject/libglib reported in the crash: 2.86.5 (libgobject-2.0.so.0.8600.5)
- NVIDIA library present in the first core: libnvidia-glcore.so.615.71.09
- Host distribution, kernel, Flatpak version and KDE version: not yet collected

Steps observed to trigger the crash
1. Launch RDM.
2. Open and use an SSH session in RDM.
3. Close the active SSH session.
4. RDM can terminate with SIGSEGV instead of only closing the session.

Expected: The SSH session closes and RDM remains running.
Actual: The entire RDM process crashes and systemd records a core dump.

Frequency: Observed more than once, but not established to happen on every session closure. An additional idle crash was observed. I have not established whether this began with the October 2 update.

Crash evidence
Both cores identify this executable:
/app/lib/devolutions/RemoteDesktopManager/RemoteDesktopManager

First captured crash: 2026-10-07 14:14:33 CEST, host PID 26701, SIGSEGV.
Its symbolized native stack begins:
#0 g_type_check_instance_is_fundamentally_a (...) at ../gobject/gtype.c:3917
#1 g_object_remove_toggle_ref (object=0x55798d1c8360, ...) at ../gobject/gobject.c:4561
#2 0x00007f336174438f in ??? ()

Second captured crash: 2026-10-07 15:32:00 CEST, host PID 32109, SIGSEGV, on closing an active SSH session during the forced-X11 test.
Its symbolized native stack begins:
#0 g_type_check_instance_is_fundamentally_a (type_instance=0x56015b1aba30, fundamental_type=0x50 [GObject]) at ../gobject/gtype.c:3917
#1 g_object_remove_toggle_ref (object=0x56015b1aba30, notify=0x7f27fbc19b90, data=0x7f17a1c145b0) at ../gobject/gobject.c:4561
#2 0x00007f27ff713f7f in ??? ()
#3 0x00007f185acae7a0 in ??? ()
#4 0x0000000000000001 in ??? ()
#5 0x00007ffd332abad0 in ??? ()
#6 0x0000000000000000 in ??? ()

The faulting source line reported by GDB in both cases is:
node = lookup_type_node_I (type_instance->g_class->g_type);

The managed caller is not resolved by these native GDB traces. An invalid or already freed GObject is a hypothesis, not a confirmed root cause.

Troubleshooting completed
- Installed the GNOME 49 SDK and debug symbols to inspect the cores.
- Disabled GDB debuginfod retrieval and successfully obtained backtraces.
- Tested this launch command:
flatpak run --socket=x11 --nosocket=wayland --env=GDK_BACKEND=x11 com.devolutions.remotedesktopmanager
- RDM still crashed when closing an active SSH session under that launch configuration, with the same native stack signature.
- Queried the Devolutions remote using flatpak remote-info --system --log devolutions com.devolutions.remotedesktopmanager//current. It returned an empty History section, so no application rollback was tested.
- No native .deb/.rpm installation or runtime rollback has been tested.

Additional terminal messages during the forced-X11 run
(RemoteDesktopManager:2): Gtk-WARNING **: 14:30:37.594: Locale not supported by C library.
Using the fallback 'C' locale.
(RemoteDesktopManager:2): GLib-GObject-CRITICAL **: 14:30:53.233: ../gobject/gsignal.c:2437: signal 'response' is invalid for instance '0x7f17a80089b0' of type 'GtkWindow'

That warning occurred earlier in the run; a causal relationship with the later crash has not been established. Flatpak also reported reserved /etc certificate paths not being shared. GDB reported unavailable file-backed mappings and deleted memfd mappings, but successfully loaded the cores and resolved the two GObject frames.

Available diagnostic files
- rdm-backtrace.txt: first core, bt full and all-thread backtraces
- rdm-32109-backtrace.txt: second core, top 15 frames requested
- rdm-x11-test.txt: terminal output from the forced-X11 run

Please confirm whether this is a known RDM/GTK binding object-lifetime issue or a GNOME 49 runtime compatibility issue. Is there a fixed build or recommended workaround? If a managed stack trace is required, please provide the appropriate SOS/runtime-symbol collection steps for this exact Flatpak build.

rdm-backtrace.txt

rdm-x11-test.txt

rdm-32109-backtrace.txt

rdm-environment.txt

All Comments (6)

avatar

Hello,
Thank you for the very complete report and backtraces, they are very helpful.
Your traces show the crash happens on RDM’s UI thread while RDM releases a GTK object that was already freed, during the cleanup of the embedded SSH terminal. Since it still happens with X11 forced, your Wayland, NVIDIA and runtime setup don’t look like the cause.
To narrow it down, could you please provide the following:

  1. Does RDM also crash if you end the session from inside the shell (exit or logout) instead of closing the tab?
  2. How many SSH sessions were open when it crashed? Does it happen with only one session open?
  3. Does it happen with a brand-new SSH entry using default settings, or only with your existing entries?
  4. Did you first notice this after the October 2 update (2026.3.1.1), or did it also happen on 2026.3.0.5?
  5. When it crashed while idle, were any SSH sessions open or recently closed?

Best regards,

Carl Marien

avatar

The same issue happened to me as well.
I’m using Pop!_OS 24 with Wayland and the COSMIC desktop environment, and I started experiencing the crashes after updating Remote Desktop Manager to version 2026.3.0.5.
Because of the instability, I had to downgrade RDM to version 2026.2.2.2, and that version has been working normally for me.

avatar

Hello,

We were able to reproduce the crash on our side with the Flatpak version when closing an SSH session tab.

It happens in RDM itself while it cleans up the SSH terminal, so it is not caused by your desktop, Wayland, or the GNOME runtime.

We have reported it to our development team as a bug, with your backtraces and our steps to reproduce.

In our tests, the .deb package of RDM does not seem to have the issue.

Until a fix is available, we recommend uninstalling the Flatpak and installing the .deb package of the same version instead.

If the crash still happens with the .deb package, version 2026.2.2.2 is not affected and can be used as a fallback.

We will let you know as soon as a version with the fix is available.

Best regards,

Carl Marien

avatar

Hello Carl,
Thank you for the update.
I also tested the .deb version, and unfortunately the same crash occurs there as well when closing an SSH session.
Because of this, I decided to remain on version 2026.2.2.2 for now, since this version has been stable and does not present the issue in my environment.
Please let me know when a fixed version becomes available so I can test it again.
Best regards,

avatar

Hello,
Thank you for the detailed report and backtraces, they were very helpful. We reproduced the crash on our side and it has been logged with our development team as a bug (ref. RDMLI-4713). It was introduced in 2026.3.0.5; 2026.2.2.2 is not affected.
While a fix is pending, our testing shows the native .deb package of the same version does not exhibit the crash. Could you try installing RDM from the .deb (https://devolutions.net/remote-desktop-manager/home/downloadlinux/) instead of the Flatpak and let us know if the issue persists? If it does, version 2026.2.2.2 is a working fallback.
No managed stack trace is needed at this point. We’ll update you as soon as a fixed build is available.
Best regards,

Carl Marien

avatar

Hi Carl,
Thank you for your response and for confirming the bug.
I would like to clarify that my installation was already done using the native .deb package, not Flatpak, and I'm experiencing the same crashing behavior.
Please let me know if you need any additional information or logs to help investigate the issue.
Best regards.