I have a few workstations running Fedora 42, all of them without monitors, I access them remotely. My typical setup was to start vnc servers, through tigervnc server, running gnome x11 sessions.
I updated one workstation to Fedora 43, to test what could work now that x11 was removed from gnome sessions.
I configured gnome-remote-desktop and try to use the workstation through RDP, but it is completely unstable (to the point that it is unusable).
Here is a snippet of dmesg, it is filled with errors:
[137928.366390] traps: gnome-remote-de[1899807] general protection fault ip:7f2596b4451e sp:7f25837fc600 error:0 in libwinpr3.so.3.22.0[1151e,7f2596b33000+77000] [141586.767070] traps: gnome-remote-de[1941757] general protection fault ip:7f883370951e sp:7f88077fc600 error:0 in libwinpr3.so.3.22.0[1151e,7f88336f8000+77000] [145823.841544] traps: gnome-remote-de[1976974] general protection fault ip:7f7778c7e51e sp:7f7744ff7600 error:0 in libwinpr3.so.3.22.0[1151e,7f7778c6d000+77000] [146747.062814] traps: gnome-remote-de[1983820] general protection fault ip:7f8489d0951e sp:7f847e7fa600 error:0 in libwinpr3.so.3.22.0[1151e,7f8489cf8000+77000] [148865.237561] traps: gnome-remote-de[1998644] general protection fault ip:7f27b710951e sp:7f27b13fb600 error:0 in libwinpr3.so.3.22.0[1151e,7f27b70f8000+77000] [149845.825252] traps: gnome-remote-de[2006389] general protection fault ip:7f9bc569a51e sp:7f9b9dff9600 error:0 in libwinpr3.so.3.22.0[1151e,7f9bc5689000+77000] [149857.661854] gnome-remote-de[2006585]: segfault at 5584c606d569 ip 00007fb18de87905 sp 00007fb1827faba0 error 4 in libc.so.6[7a905,7fb18de0d000+16f000] likely on CPU 18 (core 34, socket 0) [149857.661881] Code: ff ff eb 91 e8 ac 79 08 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 55 48 89 e5 53 48 89 fb 48 83 ec 08 e8 1b f1 ff ff <48> 8b 03 85 c0 74 14 48 8d 50 ff f0 48 0f b1 13 75 09 48 8b 5d f8 [149945.101702] traps: gnome-remote-de[2007433] general protection fault ip:7fc1e2b2651e sp:7fc1baffb600 error:0 in libwinpr3.so.3.22.0[1151e,7fc1e2b15000+77000] [154941.277830] traps: gnome-remote-de[2049891] general protection fault ip:7f93b770951e sp:7f93b19fb600 error:0 in libwinpr3.so.3.22.0[1151e,7f93b76f8000+77000] [155488.262447] traps: gnome-remote-de[2055010] general protection fault ip:7efe1f8ae51e sp:7efe189f9600 error:0 in libwinpr3.so.3.22.0[1151e,7efe1f89d000+77000] [157567.452142] traps: gnome-remote-de[2070561] general protection fault ip:7feb54a9f51e sp:7feb4cbf7600 error:0 in libwinpr3.so.3.22.0[1151e,7feb54a8e000+77000] [159128.002089] traps: gnome-remote-de[2081592] general protection fault ip:7fd7f4b0751e sp:7fd7d77fc600 error:0 in libwinpr3.so.3.22.0[1151e,7fd7f4af6000+77000] [159414.704933] traps: gnome-remote-de[2085193] general protection fault ip:7f14a2f0951e sp:7f148cff7600 error:0 in libwinpr3.so.3.22.0[1151e,7f14a2ef8000+77000] [161700.851161] traps: gnome-remote-de[2102406] general protection fault ip:7f48860de51e sp:7f487affb600 error:0 in libwinpr3.so.3.22.0[1151e,7f48860cd000+77000] [163743.343824] traps: gnome-remote-de[2118712] general protection fault ip:7fd2126dc51e sp:7fd1eaffb600 error:0 in libwinpr3.so.3.22.0[1151e,7fd2126cb000+77000] [164803.898865] traps: gnome-remote-de[2127231] general protection fault ip:7f63b190951e sp:7f637bffd600 error:0 in libwinpr3.so.3.22.0[1151e,7f63b18f8000+77000] [165385.869758] traps: gnome-remote-de[2131823] general protection fault ip:7ff4d889651e sp:7ff4d09f7600 error:0 in libwinpr3.so.3.22.0[1151e,7ff4d8885000+77000] [165975.390257] traps: gnome-remote-de[2136283] general protection fault ip:7f3b858cf51e sp:7f3b7d9f7600 error:0 in libwinpr3.so.3.22.0[1151e,7f3b858be000+77000] [166298.940458] traps: gnome-remote-de[2138644] general protection fault ip:7f1246ef451e sp:7f12317f8600 error:0 in libwinpr3.so.3.22.0[1151e,7f1246ee3000+77000] [166583.860244] traps: gnome-remote-de[2141243] general protection fault ip:7f4ff113951e sp:7f4fe91f7600 error:0 in libwinpr3.so.3.22.0[1151e,7f4ff1128000+77000] [169389.035998] traps: gnome-remote-de[2164627] general protection fault ip:7f9bdfb0f51e sp:7f9bb37fc600 error:0 in libwinpr3.so.3.22.0[1151e,7f9bdfafe000+77000] [170489.296718] traps: gnome-remote-de[2181193] general protection fault ip:7f286deea51e sp:7f2860ff7600 error:0 in libwinpr3.so.3.22.0[1151e,7f286ded9000+77000] [174847.878054] traps: gnome-remote-de[2277293] general protection fault ip:7fd75830951e sp:7fd738ff7600 error:0 in libwinpr3.so.3.22.0[1151e,7fd7582f8000+77000] [175071.893269] gnome-remote-de[2279622]: segfault at 55faa3cccd30 ip 000055faa3cccd30 sp 00007f1f4f7fc5f8 error 15 likely on CPU 16 (core 32, socket 0) [175071.893290] Code: 00 00 00 72 00 00 00 00 00 00 e0 1f 00 58 1f 7f 00 00 01 00 00 00 1f 7f 00 00 a0 e3 cc a3 fa 55 00 00 02 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 31 00 00 00 00 00 00 00 a0 4d a5 a4 fa 55 [175549.479143] gnome-remote-de[2282974]: segfault at 55eeab788760 ip 000055eeab788760 sp 00007efe67ffd5f8 error 15 likely on CPU 16 (core 32, socket 0) [175549.479164] Code: 00 00 30 1e 2d 93 fe 7e 00 00 01 00 00 00 00 00 00 00 60 08 2d 93 fe 7e 00 00 80 4d 89 ab ee 55 00 00 00 00 00 00 00 00 00 00 <90> 03 94 96 ee 55 00 00 41 00 00 00 00 00 00 00 b0 33 89 ab ee 55 [176998.743310] traps: gnome-remote-de[2295047] general protection fault ip:7fd6f850951e sp:7fd6dbffd600 error:0 in libwinpr3.so.3.22.0[1151e,7fd6f84f8000+77000] [177040.304013] traps: gnome-remote-de[2295602] general protection fault ip:7f950850951e sp:7f94ea7fa600 error:0 in libwinpr3.so.3.22.0[1151e,7f95084f8000+77000] [178987.709701] traps: gnome-remote-de[2320552] general protection fault ip:7f883250951e sp:7f88067fa600 error:0 in libwinpr3.so.3.22.0[1151e,7f88324f8000+77000] [179117.783422] traps: gnome-remote-de[2322142] general protection fault ip:7f2638f0951e sp:7f2632bfa600 error:0 in libwinpr3.so.3.22.0[1151e,7f2638ef8000+77000] [179515.718525] traps: gnome-remote-de[2327028] general protection fault ip:7fca866b351e sp:7fca78ff7600 error:0 in libwinpr3.so.3.22.0[1151e,7fca866a2000+77000]
Searching the bug database, I found many unresolved bugs on gnome-remote-desktop.
And I tried, gnome sessions no longer start in tigervnc servers.
What are my alternatives? How can I use a headless workstation in Fedora 43?
This is a repeating crash, likely within the same function according to consistency in the reported instruction pointers, in the libwinpr3 library.
Known bug perhaps - I’d hazard a guess that this library is used heavily in RDP sessions, or is maybe part of the Gnome Remote Desktop (not a Gnome user so cannot confirm).
Could you use coredumpctl -r to look up the PID of the crashed process and then run coredumpctl gdb <PID_OF_THE_CRASHED_PROCESS> (e.g. coredumpctl gdb 1234 if that PID was 1234)? That will open gdb with that crashed process. Then with bt full you can get the stacktrace of that crashed process. Could you attach that output here (or via pastebin (or similar))?
Without a stacktrace with debug symbols, there is no way to find out the cause of that.
warning: could not find supplementary DWARF file (/root/.cache/debuginfod_client/0c2b68538fccf800ab70a48d292100833e3ad196/../../.dwz/freerdp-3.22.0-1.fc43.x86_64) for /root/.cache/debuginfod_client/0c2b68538fccf800ab70a48d292100833e3ad196/debuginfo
Core was generated by `/usr/libexec/gnome-remote-desktop-daemon --system’. Program terminated with signal SIGSEGV, Segmentation fault. ❌️ could not find supplementary DWARF file Python Exception <class ‘gdb.error’>: could not find supplementary DWARF file (gdb) bt Python Exception <class ‘gdb.error’>: could not find supplementary DWARF file ❌️ could not find supplementary DWARF file
So it is the system daemon that crashes (that one accepts the connecting client and transfers it to the actual user session, where the handover daemon takes over for the actual session).
#0 0x00007f833e91251e in winpr_Handle_getFd (handle=0x562c7c00e8d0) at ./winpr/libwinpr/synch/../handle/handle.h:174
hdl = 0x562c7c00e8d0
type = 412659822 #1 winpr_Handle_getFd (handle=0x562c7c00e8d0) at ./winpr/libwinpr/synch/../handle/handle.h:166
It’s actually not possible to normally crash here. It very much looks like memory corruption. There was actually a regression found in the persistent session handling recently, which was fixed in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/370 for GNOME 50. It is likely that this here is the same issue despite different stacktraces (memory corruption can have different appearances). I created a backport for the fix in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/381, which will be part of GNOME Remote Desktop 49.3, which will probably be released on monday. Then Fedora can pick up that patched version.
@petasis
GNOME Remote Desktop 49.3 is now released upstream-wise. There is now already a Fedora build at bodhi here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a4fcd23d3e
As soon as the build is finished (I guess this may need some hours), there will be a How to install section on that page with a command on how you can install that bugfix release.
hm…that’s strange. Could you attach the stacktrace for t a a bt full as well (stacktrace with all threads). Basically instead of running bt full just run t a a bt full and attach the output here.
Another quick question: gdb still says Core was generated by /usr/libexec/gnome-remote-desktop-daemon --system’. Program terminated with signal SIGSEGV, Segmentation fault., right? (the --system part and the SIGSEGV part are the relevant ones here (so, that it is not suddenly the handover daemon, etc))
Those are quite frequent hits that you have here in coredumpctl - all with the system daemon (visible due to the userid being lower than 1000).
Your threaded stacktrace seems to be a different one than the one that you had in comment 8. Here it seems the crash happens when the sessions shuts down, presumably after sending the Server Redirection PDU and after the client disconnected for reconnection with the routing token. However, like the non-threaded stacktrace, the trace does not make much sense: Here the crash happens when clearing the peer context, because the socket thread still appears to be running. But that is not possible, because the code is only able to run when the socket thread is gone.
You mentioned that the crashes started to appear after upgrading to F43, so I’ve looked into the changes between 48.x and 49.x. However, there are no changes affecting the system daemon. There are changes for the system daemon in g-r-d-50, but that does not matter here.
I’ve looked through Ubuntu Errors (Ubuntus crash tracker) and there are no similar crash hits. With the frequent amount of hits that you have here, I would have expected something similar there (since Ubuntus user base is larger). There are also no reports from Archlinux users with such situation here. With that said, I’m starting to think whether there was some kind of error happening during the F43 upgrade on your system. Otherwise, there would be similar cases on those other distributions. Is there a possibility that you could try to reproduce the issue on a new clean install of F43? I wonder whether the Fedora upgrade process broke something here.
Thank you for looking into this. I have many core dumps in my system, gnome-remote-desktop crashes 10-20 times per day. I think I have used the same core dump id though (but I may be wrong).
My problem started when I upgraded to fedora 43, because until fedora 42 I was using the X11 gnome session, under tigervnc. In fedora 43 this has been removed, so I switched to gnome-remote-desktop after the update to fedora 43. In fedora 43 gnome-remote-desktop was never stable for me.
The crashes to happen during logging out is impossible: gnome-remote-desktop always crashed when I am logged in, while working. In some cases, it crashes on its own, without any login.
I just run a system verification, there are 20 packages that no matter how many times I reinstall them, they again fail verification: