PuTTY semi-bug rdesktop-paste-hang

Home | Licence | FAQ | Docs | Download | Keys | Links
Mirrors | Updates | Feedback | Changes | Wishlist | Team

summary: Paste from tunneled Remote Desktop session into PuTTY causes hang
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: taxing: Needs external things we don't have (standards, users etc)
present-in: 0.53b 2004-02-12 0.56 0.57 0.58
fixed-in: 2008-11-29 r8338 (0.61) (0.62) (0.63)

We've had a few reports that the following scenario causes PuTTY to hang ("Not responding"):

  1. Set up a PuTTY session with a tunnel for a Remote Desktop session.
  2. Copy text from the Remote Desktop session.
  3. Paste it into the PuTTY session running the tunnel.
Closing the Remote Desktop session apparently unwedges PuTTY.

This sounds like a classic deadlock. This looks plausible if Terminal Services defers sending clipboard data over the network until it's requested; PuTTY does all the operations involved in a paste without explicitly checking for and dealing with any network activity.

It seems that the data is only hauled over the network once; if it's pasted into another local applicaton and then pasted into the tunnelling PuTTY without re-selecting, it works (at least with XP Pro SP2 as the server).

However, we haven't been able to reproduce it ourselves (with XP SP1). We've had one report that it only happens when pasting from certain applications on the Remote Desktop end (mIRC is one such), which could explain that (or could just turn out to be a mistaken correlation caused by the effect mentioned above).

Another workaround is apparently to paste into some other local application and re-copy from there before pasting into PuTTY.

This deadlock can also show up when copying data from a tunnelled X session and pasting into the PuTTY session doing the tunnelling; this has been reported with Seagull Software BlueZoneX versions 7 and up.

Reports:

Audit trail for this semi-bug.


If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2008-11-28 18:28:54 +0000)