Jorge Schrauwen wrote: > Yeah I figured it out a bit later and it indeed seems broke. Not sure > whats wrong though I posted a debug log + user dump yesterday.
The debug log was unfortunately not very interesting, since it wasn't doing anything out of the ordinary at the time you interrupted the process. It's also not quite decipherable, you would have to build at minimum with /Oy- and ideally with /Zi for your compile flags, /debug (to create pdb's also for third party modules) to the linker. And to let Dr Watson dig through all the particularities of your system libraries, you can use WinDbg (a free download from MS) which has a very nice feature; you set up a local SymStore that can suck down the .pdb's of almost any Microsoft shipped .dll through an envvar that looks like; _NT_SYMBOL_PATH=srv*G:\symstore*http://msdl.microsoft.com/download/symbols ...like magic your crash dumps will include all backtraces through the win32 dll's and nt kernel. We do know something more about this flaw at this point; you'll find most of the details at http://issues.apache.org/bugzilla/show_bug.cgi?id=43329 Thankfully Tom's created this incident after (correctly) diagnosing what libfcgid does on Win32. It's trivial to solve, as Tom noted and I had further corrected in that incident, however it reverts to existing broken behavior with respect to APR. Apparently mod_fcgid has long assumed that invalid handles are it's clue that it should run. Foolish Win32-ish assumption; and the way it behaves when compiled under VC6 and VC8 seem to significantly disagree. This might be because VC8 tries to be more clever about "repairing" broken stdhandles for console applications. The bottom lines are these; the APR library exists to keep applications consistent - the basic behavior is that fd's 0, 1, 2 (Win32's STD HANDLE values) inherit the parent's pipes if not explicitly defined; some apps fail miserably when runing in a service context with a sub-par set of handles (e.g. cmd.exe for one, while on unix a program will open a file only to discover that fd occupies slot 0, 1, or 2 and becomes corrupted). So the question becomes; fix libfcgid? And/or; add an explicit and very platform independent feature to NOT inherit undefined handles from the parent to child process? If this feature were added, it would be possible to say NO_PIPE to all three handles, and on unix have fd's 0/1/2 all unused, on windows have them all contain INVALID_HANDLE_VALUE's. I'm sure there is a valid use case for this across platforms. Bill
