mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-15 01:58:05 -05:00
810e21de82
Whenever we successfully send some data to standard output/error, we're supposed to notify the backend that this has happened, and tell it how much backlog still remains, by calling backend_unthrottle(). In Unix Plink, the call to backend_unthrottle() was happening on some but not all calls to try_output(). In particular, it was happening when we called try_output() as a result of stdout or stderr having just been reported writable by poll(), but not when we called it from plink_output() after the backend had just sent us some more data. Of course that _normally_ works - if you were polling stdout for writability at all then it's because a previous call had returned EAGAIN, so that's when you _have_ backlog to dispose of. But it's also possible, by an accident of timing, that before you get round to doing that poll, the seat passes you further data and you call try_output() anyway, and by chance, the blockage has cleared. In that situation, you end up having cleared your backlog but forgotten to tell the backend about it - which might mean the backend never unfreezes the channel or (in 'simple' mode) the entire SSH socket. A user reported (and I reproduced) that when Plink is compiled on MacOS, running an interactive session through it and doing output-intensive activity like scrolling around in htop(1) can quite easily get it into what turned out to be that stuck state. (I don't know why MacOS and not any other platform, but since it's a race condition, that seems like a plausible enough cause of a difference in timing.) Also, we were inconsistently computing the backlog size: sometimes it was the total size of the stdout and stderr bufchains, and sometimes it was just the size of the one we'd made an effort to empty. Now the backlog size is consistently stdout+stderr (the same as it is in Windows Plink), and the call to backend_unthrottle() happens _inside_ try_output(), so that I don't have to remember it at every call site.
This is the README for PuTTY, a free Windows and Unix Telnet and SSH
client.
PuTTY is built using CMake <https://cmake.org/>. To compile in the
simplest way (on any of Linux, Windows or Mac), run these commands in
the source directory:
cmake .
cmake --build .
Then, to install in the simplest way on Linux or Mac:
cmake --build . --target install
On Unix, pterm would like to be setuid or setgid, as appropriate, to
permit it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) The cmake install step
doesn't attempt to add these privileges, so if you want user login
recording to work, you should manually ch{own,grp} and chmod the
pterm binary yourself after installation. If you don't do this,
pterm will still work, but not update the user login databases.
Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory using `doc/Makefile'. If you aren't using one of our
source snapshots, you'll need to do this yourself. Halibut can be
found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
https://www.chiark.greenend.org.uk/~sgtatham/putty/
If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.
See the file LICENCE for the licence conditions.