Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <20001114061727.22682.qmail@web106.yahoomail.com> Date: Tue, 14 Nov 2000 00:17:27 -0600 (CST) From: =?iso-8859-1?q?Edgar=20Ruiz=20Rojas?= <_espartaco AT yahoo DOT com> Subject: Re: processes under Win9x... To: cygwin AT sourceware DOT cygnus DOT com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Ken I had a similar experience with processes in Apache port for cygwin but, in my case, it was with the version 1.3.9 distribuited in the Web site of cygwin porting project http://www.student.uni-koeln.de/cygwin/Distribution/Source/apache/ I have gcc 2.95.2 and cygwin 1.1.4 (2000-08-03) and my system of work is Windows 98; the visualization of Web pages is good, but when I tried run the CGI scripts, the child processes gone to state as well as in your same situation. I had beed depuring the first chield proccess whit the purpose of find the instruction or the function in which the error ocurrs, and I believe that I already discovered the source of the problem. In appearance, Apache fail whit CGI scripts in Windows 98 when it come to function ap_select (in file http_protocol.c). At this point, the program stay stopped until TIMEOUT variable expires (this variable is defined in httpd.conf, with default to 300 sec), but this last function isn't the real cause of the problem. The true error ocurrs in the primitive function read (located at buff.c, inside of function ap_read), because this primitive don't wait, but that it returns inmediatly whitout reading any data; by this reason, the read function returns a value of -1, and it don't breaks the later processes. The cause of why the read function don't wait for any input, is because the O_NONBLOCK flag is set for the file fb->fd_in. Setting the next patch for avoid the non-blocking of this file, the problem is resolved, at least on Win98: diff -urN apache_1.3.9-cygwin/src/main/http_protocol.c apache_1.3.9-cygwin1/src/main/http_protocol.c --- apache_1.3.9-cygwin/src/main/http_protocol.c Sat Aug 14 09:21:20 1999 +++ apache_1.3.9-cygwin1/src/main/http_protocol.c Tue Nov 14 00:03:40 2000 @@ -2065,7 +2065,7 @@ /* Make fb unbuffered and non-blocking */ ap_bsetflag(fb, B_RD, 0); -#ifndef TPF +#if !defined(TPF) && !defined(__CYGWIN__) && !defined(__CYGWIN32__) ap_bnonblock(fb, B_RD); #endif fd = ap_bfileno(fb, B_RD); I don't had tested this patch on WinNT system (because I have'n any system on my work whit this OS); I'll give thanks to all people that can test this on WinNT and say me the results obtained. Some others changes to the source that I applied to this port of Apache were: diff -urN apache_1.3.9-cygwin/src/main/http_main.c apache_1.3.9-cygwin1/src/main/http_main.c --- apache_1.3.9-cygwin/src/main/http_main.c Sat Oct 2 17:15:52 1999 +++ apache_1.3.9-cygwin1/src/main/http_main.c Tue Nov 14 00:05:54 2000 @@ -2911,8 +2911,8 @@ int x; chdir("/"); -#if !defined(MPE) && !defined(OS2) && !defined(TPF) && \ - !defined(__CYGWIN__) && !defined(__CYGWIN32__) +#if !defined(MPE) && !defined(OS2) && !defined(TPF) /* && \ + !defined(__CYGWIN__) && !defined(__CYGWIN32__) */ /* Don't detach for MPE because child processes can't survive the death of the parent. */ if ((x = fork()) > 0) diff -urN apache_1.3.9-cygwin/configure apache_1.3.9-cygwin1/configure --- apache_1.3.9-cygwin/configure Sat Aug 14 08:29:06 1999 +++ apache_1.3.9-cygwin1/configure Tue Nov 14 00:07:08 2000 @@ -241,6 +241,9 @@ iflags_program="$iflags_program -e .exe" iflags_core="$iflags_core -e .exe" ;; + *-cygwin32* ) + iflags_program="$iflags_program -e .exe" + ;; esac # various other flags diff -urN apache_1.3.9-cygwin/src/support/logresolve.c apache_1.3.9-cygwin1/src/support/logresolve.c --- apache_1.3.9-cygwin/src/support/logresolve.c Mon Jul 13 11:33:00 1998 +++ apache_1.3.9-cygwin1/src/support/logresolve.c Tue Nov 14 00:10:06 2000 @@ -95,7 +95,7 @@ * statistics - obvious */ -#ifndef h_errno +#if !defined(h_errno) && !defined(__CYGWIN__) && !defined(__CYGWIN32__) extern int h_errno; /* some machines don't have this in their headers */ #endif Regards, Edgar Ruiz On Mon, Jun 05, 2000 at 11:00:47AM -0700, Ken Coleman wrote: >I've debugged a problem I reported a few weeks ago a little bit more, >and I can tell you fairly well what's happening. > >I'm trying to get Apache 1.3.12 running, and when I run CGI scripts, >the subprocesses that run the script become and stay that way >forever. It fork()s Apache, then calls one of the exec() functions to >run the CGI script synchronously. In one of the processes, it's >spinning at the top of wait_subproc in sigproc.cc. It's appears that >it will be in the loop forever, although I haven't let the processes >run for more than a few minutes. > >In that function, WaitForMultipleObjects() is consistently returning >WAIT_TIMEOUT, but proc_loop_wait is still 500. It appears that you set >it to 0 when it's time for the process to terminate, but somehow that >has not occurred. The process has already received several >PROC_CHILDTERMINATED signals into proc_subproc, which is why it's set >to in the process table (zombie flag is set). > >Any help would be greatly appreciated. There are several strace logs >that I sent in my earlier message that may be useful - it's dated >5/23/2000. It works under WinNT (I ran it on my work system), but >fails under Win9x. There are two strace logs - one for each OS. I >know you hate dealing with Win9x, but I just can't really upgrade this >system to Win2K. _________________________________________________________ Do You Yahoo!? Obtenga su dirección de correo-e gratis @yahoo.com en http://correo.espanol.yahoo.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com