Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <000701c0ec66$68034d00$4c93a5d8@msrv>
From: "Joe Hagen" <jdhagen AT chorus DOT net>
To: <cygwin AT cygwin DOT com>
Subject: Cygwin handle leak in net.cc
Date: Sun, 3 Jun 2001 14:50:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000

Chris,

I believe there's a handle leak occurring in 
net.cc.

The functions recv/recfrom and send/sendto use
the wsock_event class that obtains a handle using
WSACreateEvent.

wsock_event::prepare allocates the handle.

When this class is used, if wsock_event::wait isn't
invoked, the handle won't be freed.

I observed this in the recv function.

  In Windows NT's Task Manager, I was watching 
fetchmail's handle count, and it quickly grew to 60,000.
I modified the fetchmail source to obtain its handle
count using NtQueryInformationProcess from NTDLL.DLL,
and recv() was the culprit.

If the wsock_event class was modified with a destructor
that did this:

    wsock_event::~wsock_event
    {
        if (event)
        {
               WSACloseEvent(event);
               event=0;
        }
    }

I think this would fix the problem.

This would ensure the handle is freedl when 
the object goes out of scope.

Joe


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple