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

[Commits to Tartarus CVS repository.]

TL;DR:
  7549f2d Fix handle leak in winhandl.c.
  087ca59 Mark handles defunct before calling gotdata/sentdata.

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: pre-0.64
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-02-07 13:14:31

commit 7549f2da40d3666f2c9527d84d9ed5468e231691
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=7549f2da40d3666f2c9527d84d9ed5468e231691;hp=8dedf59080d1318ede64c12b99b1a3a2c321d304
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Feb 7 11:48:19 2015 +0000

    Fix handle leak in winhandl.c.
    
    The code for cleaning up handle structures works by the main thread
    asking the per-handle subthread to shut down by means of setting its
    'done' flag, and then once the subthread signals back through its
    event object that it's done so, the main thread frees all its
    resources and removes the event object from the list of things being
    checked in the program's event loop.
    
    But read threads were not sending back that final event acknowledging
    a request to shut down, so their event objects were never being
    cleaned up.
    
    Bug spotted by Ronald Weiss.

 windows/winhandl.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

commit 087ca595f3f612f0d2de1d406b5fcc751cdd3566
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=087ca595f3f612f0d2de1d406b5fcc751cdd3566;hp=7549f2da40d3666f2c9527d84d9ed5468e231691
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Feb 7 12:39:47 2015 +0000

    Mark handles defunct before calling gotdata/sentdata.
    
    If (say) a read handle returns EOF, and its gotdata function responds
    by calling handle_free(), then we want the handle to have already had
    its defunct flag set so that the handle can be destroyed. Otherwise
    handle_free will set the 'done' flag to ask the subthread to
    terminate, and then sit and wait for it to say it's done so -
    forgetting that it signalled termination already by returning EOF, and
    hence will not be responding to that signal.
    
    Ditto for write errors on write handles, though that should happen
    less often.

 windows/winhandl.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)