rdesktop causes hard lockup of X server input, preventing further interaction with system
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| rdesktop (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: rdesktop
rdesktop 1.6.0-2ubuntu1
Also seems to interact with: nautilus 1:2.24.0-0ubuntu1
At semi-random intervals, rdesktop appears to be responsible for locking up the entire X-server input loop; at least the keyboard stops responding altogether, until rdesktop is killed by some means (usually by logging in remotely from another system).
The problem appears to occur most frequently (nearly 100% of the time) when attempting to interact with the clipboard, to copy and paste (direction doesn't seem to matter too much, but this error occurs for me most frequently when copying *from* the remote session).
After this happens, when I'm able to terminate rdesktop, I get an error message "Warning: Unable to obtain primary clipboard", usually repeated several times, often so many times that the dialog ends up extending offscreen.
Additionally, this seems to be interacting with Nautilus in some way, as I typically have to kill both rdesktop and nautilus before things work again.
| David Breakey (david-breakey) wrote | #1 |
| Szymon Życiński (zycinski) wrote | #2 |
To clarify: when it locks up, the keyboard and GUI stop responding, although the mouse remains operational, though confined to whichever monitor it happened to be on (I have a dual-monitor setup, with two separate displays: ie: NOT linked as a single virtual display via Xinerama--due to gameplay issues with a certain Windows-based game).
It is my assumption that this is a lockup in the Xserver input loop, but I don't know for certain; the ability to move the mouse would suggest maybe not.
Additionally, rdesktop is being invoked via gnome-rdp 0.2.2-0ubuntu5, in a windowed mode.