mod_cgi/1414: CGI scripts run Apache out of handles on NT 4.0

[He...@hyperreal.org, Curtis <he...@WindTraveller.com>]

>Number:         1414
>Category:       mod_cgi
>Synopsis:       CGI scripts run Apache out of handles on NT 4.0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Nov 13 19:20:00 PST 1997
>Last-Modified:
>Originator:     hern@WindTraveller.com
>Organization:
apache
>Release:        1.3b2
>Environment:
Windows NT 4.0, MSVC 5.0, _apached (Makefile.nt, with ApacheCore.mak fixed to delete erroneous debug build dependencies on Unix-specific os files)
>Description:
On NT 4.0, when serving CGI scripts (perl in our case), Apache uses
up 2 NT handles per service until it eventually fails by running out
of handles.
>How-To-Repeat:
Run any CGI script.  We are using a Perl script.  The contents of the
script do not seem to matter.  Start the Windows NT Task Manager.  In it,
go to View/Select Columns.  In the resulting dialog, pick Handle Count at
least.  Thread Count also helps to distinguish which of the running
Apache copies is the one serving requests.  Or run Apache with -X.
Repeatedly execute the CGI script.  You will see the handle count rise by 2
each time the script executes.  Eventually Apache will crater in some way
related to running out of handles.  In our environment this happens at a count
of between 120 and 150 (so have some patience) and the first symptom is
usually that the pipe opens to the script process fails.

Note that using the debugger on the Apache image seems to have
a "reservation" effect.  The handle count jumps by 20 or so, and you
have to run the CGI script 10 times or so before the handle count
begins to rise again.  For a while I thought the problem only arose
outside the dubugger due to this effect.

I've spent some time trying to track this down without success.  Since handles
can be created by a variety of NT procedures, it is difficult to determine
which created handles are not being closed.  Further, the file handle table
does not seem to be full when the error finally occurs.  The traces generated by
the ResKit APIMON program are not very informative due to the raw hex
output format - you can't really track handle creation and deletion.  I was able
to put breakpoints on all the routines I know of that create handles, but some
are obviously slipping by me.
>Fix:
No, but if anyone has suggestions, I will be willing to try them.  In the
absence of a fix, workarounds would also be welcome.  For instance, I'm
thinking of checking the maximum file handle value after each service, and
suiciding the "child" server if it gets "too high".  I would rely on the "parent"
copy of the server to start a new child copy.  I'm not sure where a good place
to put this workaround would be, so a suggestion on that would also
be welcome.  Right now we can only serve 15 - 20 requests before
doomsday arrives..
>Audit-Trail:
>Unformatted: