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
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

- Raw text -