simon-git: putty (pre-0.77): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  0613ec99 Add a docs note about DNS performed by GSSAPI.
  ee987ce4 pterm.exe: fix handling of Windows exception codes.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: pre-0.77
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-03-10 13:11:14

commit 0613ec9986f0862886c1391726a4c31b1d08360d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=0613ec9986f0862886c1391726a4c31b1d08360d;hp=f85716be45a0cd47085c978744a6276fe189175e
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Feb 22 18:43:53 2022 +0000

    Add a docs note about DNS performed by GSSAPI.
    
    I recently noticed a mysterious delay at connection startup while
    using an SSH jump host, and investigated it in case it was a bug in
    the new jump host code that ought to be fixed before 0.77 goes out.
    
    strace showed that at the time of the delay PuTTY was doing a DNS
    lookup for the destination host, which was hanging due to the
    authoritative DNS server in question not being reachable. But that was
    odd, because I'd configured it to leave DNS lookup to the proxy,
    anticipating exactly that problem.
    
    But on closer investigation, the _proxy_ code was doing exactly what
    I'd told it. The DNS lookup was coming from somewhere else: namely, an
    (unsuccessful) attempt to set up a GSSAPI context. The GSSAPI library
    had called gethostbyname, completely separately from PuTTY's own use
    of DNS.
    
    Simple workaround for me: turn off GSSAPI, which doesn't work for that
    particular SSH connection anyway, and there's no point spending 30
    seconds faffing just to find that out.
    
    But also, if that puzzled me, it's worth documenting!

 doc/config.but | 10 ++++++++++
 1 file changed, 10 insertions(+)

commit ee987ce4cdc35578207e7cd02837292f5b23ebdd
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ee987ce4cdc35578207e7cd02837292f5b23ebdd;hp=0613ec9986f0862886c1391726a4c31b1d08360d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Mar 8 18:05:48 2022 +0000

    pterm.exe: fix handling of Windows exception codes.
    
    Unlike on Unix, a Windows process's exit status is a DWORD, i.e. a
    32-bit unsigned integer. And exit statuses seen in practice can range
    up into the high half of that space. For example, if a process dies of
    an 'illegal instruction' exception, then the exit status retrieved by
    GetExitCodeProcess will be 0xC000001D == STATUS_ILLEGAL_INSTRUCTION.
    
    If this happens to the process running inside pterm.exe, then
    conpty->exitstatus will be set to a value greater than INT_MAX, which
    will cause conpty_exitcode to return -1. Unfortunately, a -1 return
    from conpty_exitstatus is treated by front ends as saying that the
    backend process hasn't exited yet, and is still running. So pterm will
    sit around after its subprocess has already terminated, contrary to
    your 'close on exit' setting.
    
    Moreover, when cmd.exe exits, it apparently passes on to its parent
    process the exit status of the last subcommand it ran. So if you run a
    Windows pterm containing an ordinary interactive console session, and
    the last subprogram you happen to run inside that session dies of a
    fatal signal, then the same thing will happen after you type 'exit' at
    the command prompt.
    
    This has been happening to me intermittently ever since I created
    pterm.exe in the first place, and I guessed completely wrong about the
    cause (I feared some kind of subtle race condition in pterm's use of
    the process API). I've only just managed to reproduce it reliably
    enough to debug, and I'm relieved to find it's much simpler than that!
    
    The immediate fix, in any case, is to ensure we don't return -1 from
    conpty_exitcode unless the process really is still running. And don't
    return INT_MAX either, because that indicates 'unclean exit' in a way
    that triggers 'close window only on clean exit' (and even Unix pterm
    doesn't consider the primary subprocess dying of a signal to count as
    unclean). So we clip all out-of-range Windows exception codes to
    INT_MAX-1.
    
    In the longer term I think it would be nice to turn exit codes into a
    full 32-bit space, and move the special values completely out of it.
    That would permit actually keeping the exact exception code and
    passing it on to a caller who needed it. For example, if we were to
    write a Windows psusan (which I could imagine being occasionally
    useful), this way it would be able to return the unmodified full
    Windows exit code via the "exit-status" chanreq. But I don't think we
    currently have any clients needing that much detail, so that's a more
    intrusive cleanup for a later date.

 windows/conpty.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)