PuTTY bug unclean-close-crash
This is a mirror. The primary PuTTY web site can be found
here.
Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
summary: Reports of crashes on unclean close (related to port forwarding?)
class: bug: This is clearly an actual problem we want fixed.
present-in: 0.55 0.56 2004-11-29 2005-01-16 2005-01-24 2009-02-10
We are getting persistent reports of PuTTY crashing when a session is
closed uncleanly, for instance by a network error such as "software
caused connection abort". This limits the usefulness of the ability to
restart dead sessions that was
introduced in recent releases.
(Some people are apparently in the habit of hibernating their machines
with active PuTTY connections. When the machines come back up, the
network connections are likely to be invalid, so PuTTY throws a
network error and gives the same problem.)
Many (all?) of the reports indicate that port-forwarding is in use.
We've not yet been able to reproduce it.
See also unclean-close-hang,
which seems more or less specific to Windows Vista and Windows 7, and
definitely doesn't require port forwarding to be active.
Reports:
- OF9474F5EC.6EF0B984-ON80256E55.00617997-80256E55.0061B13F@plasmon.co.uk
0.53b; pfd; NULL ptr ref?
- [email protected]
0.53+(0.53b, 0.54?); pfd; SCCA
debug info -- apparent use of bogus ssh
- [email protected]
0.55; pfd; network error; sending on port causes crash
- [email protected]
0.56; pfd; SCCA; PuTTY using excessive CPU
- [email protected]
0.56, r4918(2004-11-29); pfd; SCCA
also assertion ssh.c:3365 ssh->state == SSH_STATE_CLOSED
- [email protected]
0.56, 2005-01-16; pfd; SCCA; tunnels still open; Dr Watson
- [email protected]
0.56 and 2005-01-24; pfd; SCCA; stack backtrace
(apparent use of bogus ssh)
also sees assertion ssh.c:3365 ssh->state == SSH_STATE_CLOSED with 0.56
- [email protected]
0.55/0.56; pfd; SCCA
also SOCKS connections not killed (fixed in 2005-02-18)
- [email protected]
0.56; XPSP1; SSH server disconnect ("connection timed out" is fine!)
- [email protected]
2009-02-10; evidence of use of freed memory (this one fixed in
r9069)
Possibly related code activity:
- access of freed ssh->channels fixed r4946, s/s 2004-12-03
- leaving channels/listening sockets lying around fixed r5325, s/s
2005-02-18
- not properly closing port-forwardings in CHAN_SOCKDATA_DORMANT state,
fixed r9069, s/s 2011-01-04
Audit trail for this bug.
If you want to comment on this web site, see the
Feedback page.
(last revision of this bug record was at 2011-01-05 11:52:30 +0000)