You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Jim Patterson <Ji...@Cognos.COM> on 1999/10/19 22:57:51 UTC

os-windows/5171: Apache server goes into an infinite loop after CGI error

>Number:         5171
>Category:       os-windows
>Synopsis:       Apache server goes into an infinite loop after CGI error
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Oct 19 15:10:01 PDT 1999
>Last-Modified:
>Originator:     Jim.Patterson@Cognos.COM
>Organization:
apache
>Release:        1.3.9
>Environment:
Windows NT 4.0 SP4
Visual C++ 5.0 SP3
>Description:
ap_read
bur_read
saferead_guts
read_with_errors
ap_bgets
cgi_handler
ap_invoke_handler
process_request_internal
ap_process_request
child_sub_main
child_main
_threadstartex
>How-To-Repeat:
I think that this is a timeout problem - the CGI timed out. It could also be a 
failure in the CGI but I don't think so. If you arent satisfied by my proposed
fix, I will attempt to create a CGI that will reproduce it for you.
>Fix:
The problem appears to be an invalid assumption by saferead_guts (src/main/buff.c) 
on Win32, or an improper Win32 implementation of ap_read (same file). 

saferead_guts loops until it gets no error or the error is other than EINTR.
However, ap_read for Win32 calls the Win32 API function ReadFile directly.
Because it's not using the C RTL, errno isn't set. If a) ReadFile fails and 
b) errno has the value EINTR initially, saferead_guts retries the read. In
my situation, the cgi process has gone away so ReadFile persistently returns
an error status. Because no code is setting the errno flag, it loops endlessly.

Since I presume ReadFile is being used for a valid reason (i.e. you won't
want to switch to using the C RTL read() routine), I suggest that the logic
be modified for Win32 to not check for the EINTR condition. There is no 
equivalent to the EINTR interrupt of a system call on Win32. 
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]




Re: os-windows/5171: Apache server goes into an infinite loop after CGI error

Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> >Fix:
> The problem appears to be an invalid assumption by saferead_guts
(src/main/buff.c)
> on Win32, or an improper Win32 implementation of ap_read (same file).
>
> saferead_guts loops until it gets no error or the error is other than
EINTR.

Jim,
I think you've found it!! I've spent hours trying to recreate this problem
and 'pumping-code' w/o success.  Never noticed it before, but
sendwithtimeout() issues WSASetLastError(EINTR) if a send (to the network)
times out.  buff_write, the caller, then issues errno = WSAGetLastError(),
which sets the conditions for the loop. I suspected errno was the culprit
and have been working to eliminate it in Apache 2.0.  Now we can get this
fixed in 1.3. Thanks man!

Bill