Leaking handles

[Vaishali Kedar]

Hi All,

I have a problem with leaking handles in a webserver.

The thread creation code is as follows -

STATIC FUNCTION SServer(dwparam AS DWORD) AS INT PASCAL

LOCAL oSocket AS CSocket

LOCAL nID AS DWORD

oSocket := CSocket{SOCK_STREAM}

IF oSocket:bind(5050, NULL_STRING, AF_INET)

oSocket:listen(1)

DO WHILE (TRUE)

phandle := CreateVOThread( null_ptr,0,;

@AcceptTh(),;

PTR(_CAST,oSocket),0,;

@nID)

WaitForSingleObject(phandle,INFINITE)

MemFree(pHandle)

CollectForced()

ENDDO

ENDIF

RETURN dwparam

The Memfree and Collectforced were put there just to see if they made a
difference.

Any idea what else I need to do? In the process viewer, the number of
threads remains the same whereas the number of handles goes up
continuously - as long as the webpage is being served.

The function AcceptTh - the thread serves one request and returns. So there
is no pool of waiting threads - it serves the purpose well for what I use it
for. If required I can send the code for AcceptTh as well.

Thanks,

Vaishali

[Geoff Schaller]

Vaishali.

A couple of questions. How often does it go around the loop? I am
expecting a Do While True loop to kind of keep growing the handles <g>.
Surely you would expect the number of handles to just continually grow
because there is nowhere for them to be destroyed.

I kind of also expected to see either a CloseHandle() call or an
ExitThread() call.

Why don't you need them?

Geoff

"Vaishali Kedar" <vaishal...@gordynpalmer.com.au> wrote in message
news:4951...@dnews.tpgi.com.au:

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 3715 (20081224) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Robert van der Hulst]

Hi Vaishali,
On Wed, 24 Dec 2008, at 15:36:44 [GMT +1100] (which was 05:36 where I live)
you wrote about: 'Leaking handles'

> phandle := CreateVOThread( null_ptr,0,;
> @AcceptTh(),;
> PTR(_CAST,oSocket),0,;
> @nID)
> WaitForSingleObject(phandle,INFINITE)
> MemFree(pHandle)
> CollectForced()

A handle created with CreateVOThread cannot be freed with MemFree.
You need to free with with CloseHandle().

--
Robert van der Hulst
AKA Mr. Data
Vo2Jet & Vo2Ado Support
VO & Vulcan.NET Development Team
www.heliks.nl

[Vaishali Kedar]

Yes, thanks Robert and Geoff - the CloseHandle was what was required.

Thanks again,
Regards,
Vaishali

"Robert van der Hulst" <E-55525A...@heliks.nl> wrote in message
news:11510602289.2...@heliks.nl...

[Vaishali Kedar]

Hi,

Re the leaking handles - what is the effect it has on system memory/CPU
usage?

Regards,
Vaishali

"Vaishali Kedar" <vaishal...@gordynpalmer.com.au> wrote in message

news:4958477c$1...@dnews.tpgi.com.au...

[Geoff Schaller]

Vaishali.

Not much... but if you've solved the problem, what is behind the
question?

Basically, VO has dyn mem and handle limits, which are configurable to a
degree, so you can control the effect somewhat. So if every thread stole
5KB of RAM then it is a straightline maths calculation to know when you
run out. Probably more limiting is the number of axits used and all
these things can be easily monitored through VO functions.

Geoff

"Vaishali Kedar" <vaishal...@gordynpalmer.com.au> wrote in message

news:49585a0e$1...@dnews.tpgi.com.au:

> Hi,
>
> Re the leaking handles - what is the effect it has on system memory/CPU
> usage?
>
> Regards,
> Vaishali
>
> "Vaishali Kedar" <vaishal...@gordynpalmer.com.au> wrote in message
> news:4958477c$1...@dnews.tpgi.com.au...
>
> > Yes, thanks Robert and Geoff - the CloseHandle was what was required.
> >
> > Thanks again,
> > Regards,
> > Vaishali

__________ Information from ESET NOD32 Antivirus, version of virus

signature database 3719 (20081227) __________

[Vaishali Kedar]

Hi Geoff,

When the webserver was run for 4-5 days continuously, the handle count would
go 300000+ and the CPU usage upto 50% and the webserver basically stopped
working. None of the memory usage values showed dangerously low levels. The
other application continued to work normally. What I am trying to determine
here is whether this would have an effect on other applications. The other
application which ran together with the webserver had some issues (comms
freezes) which went away if you restarted that application (not the
webserver). So my thought process is that the 2 issues were independent of
each other - as much as they can be running on the same PC.

The other application had much fewer freezes by the time the webserver
handle problem was sorted out - and since yesterday to my knowledge they
have had none. It does not seem logical to me considering that the webserver
did not need to be restarted to sort out the freezes on the other
application. There is other stuff which is too complex for this forum, but I
am basically trying to put a finger on the issues and try and separate them
if possible.

Regards,
Vaishali

"Geoff Schaller" <geo...@softxwareobjectives.com.au> wrote in message
news:VjZ5l.5427$cu....@news-server.bigpond.net.au...

[Geoff Schaller]

Ultimately your handle over-dose would have an effect but in a threaded
CPU, it would still try to give priority to running threads so it
wouldn't be memory that would blow up first but thread management
overhead. The "other' unclosed threads would be idle but ultimately the
OS would crap itself. Open task Manager and watch <g>.

"Vaishali Kedar" <vaishal...@gordynpalmer.com.au> wrote in message

news:49593c5a$1...@dnews.tpgi.com.au:

> Hi Geoff,
>
> When the webserver was run for 4-5 days continuously, the handle count would
> go 300000+ and the CPU usage upto 50% and the webserver basically stopped
> working. None of the memory usage values showed dangerously low levels. The
> other application continued to work normally. What I am trying to determine
> here is whether this would have an effect on other applications. The other
> application which ran together with the webserver had some issues (comms
> freezes) which went away if you restarted that application (not the
> webserver). So my thought process is that the 2 issues were independent of
> each other - as much as they can be running on the same PC.
>
> The other application had much fewer freezes by the time the webserver
> handle problem was sorted out - and since yesterday to my knowledge they
> have had none. It does not seem logical to me considering that the webserver
> did not need to be restarted to sort out the freezes on the other
> application. There is other stuff which is too complex for this forum, but I
> am basically trying to put a finger on the issues and try and separate them
> if possible.
>
> Regards,
> Vaishali
>
> "Geoff Schaller" <geo...@softxwareobjectives.com.au> wrote in message
> news:VjZ5l.5427$cu....@news-server.bigpond.net.au...
>

__________ Information from ESET NOD32 Antivirus, version of virus

signature database 3722 (20081229) __________