subprocess. They were intended to make sure the child process didn't
inherit anything embarrassing or inconvenient from us, such as the
master end of its own pty, but now we instead do this by making sure
to set all our own fds to not-FD_CLOEXEC on creation. This should
fix Debian bug #357520.
(This doesn't seem to work _quite_ right in uxproxy.c's invocation
of a local proxy command: both ends of a GTK internal pipe end up in
the child process's fd space. This appears to be another GTK 1 bug,
inasmuch as it goes away when I build with Colin's preliminary GTK 2
patch; for the moment I think leaving that pipe lying around is
probably less harmful than hampering the proxy process's ability to
use extra fds by prior arrangement with PuTTY's parent process.)
[originally from svn r7107]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
sk_new() on invocation; these functions become responsible for (eventually)
freeing it. The caller must not do anything with 'addr' after it's been passed
in. (Ick.)
Why:
A SOCKS5 crash appears to have been caused by overzealous freeing of
a SockAddr (ssh.c:1.257 [r2492]), which for proxied connections is
squirreled away long-term (and this can't easily be avoided).
It would have been nice to make a copy of the SockAddr, in case the caller has
a use for it, but one of the implementations (uxnet.c) hides a "struct
addrinfo" in there, and we have no defined way to duplicate those. (None of the
current callers _do_ have a further use for the SockAddr.)
As far as I can tell, everything _except_ proxying only needs addr for the
duration of the call, so sk_addr_free()s immediately. If I'm mistaken, it
should at least be easier to find the offending free()...
[originally from svn r3383]
[r2492 == bdd6633970]
