/usr/libexec/gnome-remote-desktop-daemon:11:setChannelError:rdpgfx_server_thread_func:thread_launcher:start_thread:clone3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
freerdp2 (Ubuntu) |
Fix Released
|
Medium
|
Jeremy Bícha | ||
Jammy |
Fix Released
|
Medium
|
Jeremy Bícha | ||
gnome-remote-desktop (Ubuntu) |
Invalid
|
Undecided
|
Jeremy Bícha |
Bug Description
Impact
------
The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-remote-
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://
Test Case 1
-----------
Unfortunately, we weren't able to identify a reliable test case.
We will know if this bug is fixed if errors.ubuntu.com stops reporting that error with a fully upgraded system. However, that means this update will need to be pushed to -updates
Test Case 2
-----------
Install all updates. Log out and log back in.
Open the Settings app to the Sharing page. Turn on Sharing and turn on Remote Desktop Sharing.
Turn it off then on because there may be a gnome-control-
From a second computer, connect to the first computer using Remmina.
The Remote Desktop page on the first computer provides the username and password to use. I wasn't able to get the "Remote Desktop Address" to work (maybe avahi doesn't work well?) so just use the first computer's IP address.
So something like:
RDP jeremy@192.168.1.1
Ensure that the connection works.
Then repeat the test after updating the second computer to use the updated freerdp2 since Remmina itself uses freerdp2. Basically we want to make sure things keep working after the update but also continue to work for connections between systems that aren't using the same version of freerdp2.
What Could Go Wrong
-------------------
[racb] This upload contains a significant rewrite of thread handling code. So the scope of a regression appears to be wide. Deadlocks, crashes and other race conditions may appear anywhere.
RDP Sharing using freerdp2 is a new feature for Ubuntu 22.04 LTS as part of GNOME 42.
RDP Sharing can be used for providing remote support so it's important that this feature works well because it may be difficult for the remote admin to fix issues in person.
freerdp2 is also used by the Remmina and GNOME Connections apps as the "client" app for RDP Sharing. (The GNOME feature is the "server" side.)
This fix is cherrypicked from the stable freerdp2 branch.
Changed in gnome-remote-desktop (Ubuntu): | |
status: | New → Triaged |
assignee: | nobody → Jeremy Bicha (jbicha) |
Changed in freerdp2 (Ubuntu): | |
status: | New → Triaged |
assignee: | nobody → Jeremy Bicha (jbicha) |
no longer affects: | gnome-remote-desktop (Ubuntu Jammy) |
description: | updated |
Changed in freerdp2 (Ubuntu Jammy): | |
status: | New → Triaged |
assignee: | nobody → Jeremy Bicha (jbicha) |
description: | updated |
Changed in gnome-remote-desktop (Ubuntu): | |
status: | Triaged → Invalid |
Changed in freerdp2 (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in freerdp2 (Ubuntu Jammy): | |
status: | Triaged → In Progress |
Changed in freerdp2 (Ubuntu): | |
importance: | Undecided → Medium |
Changed in freerdp2 (Ubuntu Jammy): | |
importance: | Undecided → Medium |
To provide some context, when this crash can happen: It can happen, after attempting to start a remote desktop session, when the screen is locked.
In such case, g-s directly refuses the start request and therefore the lifetime of the rdpgfx thread in FreeRDP is very short.
The journal message for this looks like this: org.freedesktop .DBus.Error. AccessDenied: Session creation inhibited`
`Failed to start remote desktop session: GDBus.Error:
Now, the error here is, that FreeRDP does not correctly wait for the rdpgfx thread to be created and this can lead to in this situation, that the rdpgfx thread is not teared down, when stopping the session, which can can lead to segfaults, like in this report or to memory corruption.
Personally, I was not able to reproduce the error. However, with the help of the journal entries I was able to find this cause. /github. com/FreeRDP/ FreeRDP/ pull/7836 takes care of the problem.
https:/
Sessions, that are not locked, should not be affected by this issue.