Mail Archives: cygwin/1996/12/18/14:36:37
I managed to buid the (half-) working Apache HTTP server (version 1.2b1)
with cygwin b17.1. The non-forking version of the server ("int one_process
= 1;" or run with -X debugging switch) works fine in my tests. There are
some deep problems (apparently) with the implementation of fork() and
select()/sockets in cygwin though, preventing it to run properly in forking
version.
1) When running under Windows 95, fork() does not work properly even in the
simple programs. The following program
========================
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
int main(int argc, char** argv)
{
int result;
printf("Here we go !\n");
result = fork();
if (result < 0) {
printf("fork returned error %d\n", errno);
} else if (result == 0) {
printf("fork returned 0\n");
} else {
printf("fork returned [%d]\n", result);
}
return 0;
}
========================
works fine under Windows NT 4.0 (producing both 0 and child pid as
expected) but fails miserably under Win95, saying:
========================
c:\a\tests>a.exe
Here we go !
fork returned [1001]
(C:\A\TESTS\A.EXE 1001) In cygwin_except_handler
(C:\A\TESTS\A.EXE 1001) Exception trapped!
(C:\A\TESTS\A.EXE 1001) exception C0000005 at 10001083
(C:\A\TESTS\A.EXE 1001) exception: ax FFFF2C3F bx 286 cx C107C0C4 dx 0
(C:\A\TESTS\A.EXE 1001) exception: si 0 di 256F2DC bp 256F3AC sp 256F2D0
(C:\A\TESTS\A.EXE 1001) exception is: STATUS_ACCESS_VIOLATION
(C:\A\TESTS\A.EXE 1001) Stack trace:
(C:\A\TESTS\A.EXE 1001) frame 0: sp = 0x256F0E8, pc = 0x1001282A
(C:\A\TESTS\A.EXE 1001) frame 1: sp = 0x256F104, pc = 0xBFF7663C
(C:\A\TESTS\A.EXE 1001) frame 2: sp = 0x256F128, pc = 0xBFF85A0A
(C:\A\TESTS\A.EXE 1001) frame 3: sp = 0x256F1C0, pc = 0xFFECBAD7
(C:\A\TESTS\A.EXE 1001) frame 4: sp = 0x256F3AC, pc = 0x10018743
(C:\A\TESTS\A.EXE 1001) frame 5: sp = 0x256F418, pc = 0x40107D
(C:\A\TESTS\A.EXE 1001) frame 6: sp = 0x256F424, pc = 0x10011BEB
(C:\A\TESTS\A.EXE 1001) frame 7: sp = 0x256FE14, pc = 0x10011BFF
(C:\A\TESTS\A.EXE 1001) frame 8: sp = 0x256FE20, pc = 0x401220
(C:\A\TESTS\A.EXE 1001) frame 9: sp = 0x256FE30, pc = 0x401012
(C:\A\TESTS\A.EXE 1001) frame 10: sp = 0x256FE38, pc = 0xBFF88FA3
(C:\A\TESTS\A.EXE 1001) frame 11: sp = 0x256FF78, pc = 0xBFF88E51
(C:\A\TESTS\A.EXE 1001) frame 12: sp = 0x256FFF4, pc = 0xBFF87870
(C:\A\TESTS\A.EXE 1001) frame 13: sp = 0x8159AF58, pc = 0x3
(C:\A\TESTS\A.EXE 1001) In cygwin_except_handler
(C:\A\TESTS\A.EXE 1001) Error while dumping state (probably corrupted
stack)
========================
The strangest thing is that when the same program is compiled and linked
under Windows NT 4.0 (on the same computer) it runs fine under Windows 95
as well. Apache seems to crash with the similar diagnostics even when built
under Windows NT.
2) As far as I understand, fork() needs the executable file of the process
to be accessible in the path. Apache does chdir("/") before forking off a
child, so if the executable is not in the path, fork() fails. While there
is an easy way to work around this (putting the executable in the path),
why can't fork() use (say) GetModuleFileName(hEXEInst) to determine the
full path to the executable ? If the code for that operation is placed
(say) in the crtXXX.o (that is in the EXE code itself), you can even pass
NULL as the instance argument, meaning the current module.
3) Other than that, fork() works fine under Windows NT, but Apache server
exhibits real strange behaviour, continuously forking new copies of itself
that die soon and not accepting any connections. Examining the error log
shows that in the main listening loop in the child_main() function (in
http_main.c) select() often (if not always) returns EACCES.
Oleg
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -