Apache for Windows can get caught in a tight loop whild handling CGI requests. Here's how:
sendwithtimeout() sets errno to EINTR on a timeout and returns SOCKET_ERROR (-1) to the caller. The caller reissues sendwithtimeout, which then succeeds. errno is left set to EINTR. Eventually, another read is attempted on one of the CGI pipes (ap_bgets in mod_cgi, or ap_send_fb_length) which goes down into ap_read. ap_read issues a Win32 ReadFile to read from the pipe. If this read fails, it returns -1 to the caller. If errno is still set to EINTR, the caller will retry the read and so the loop begins. The solution is quite simple. buff.c relies heavily on errno. Anytime Win32 calls are used in code that uses errno, we need to always, ALWAYS explicitly set errno when a Win32 system call fails (via either errno = GetLastError() or errno = WSAGetLastError()). Since Win32 does not use EINTR, this problem should not occur. PR: 3599 3971 4245 4430 4758 5171 Submitted by: Thanks to Jim.Patterson@cognos.com who discovered the loopig section of code. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@84018 13f79535-47bb-0310-9956-ffa450edef68
Please register or sign in to comment