apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43329] - apr_proc_create behavior change
Date Sun, 09 Sep 2007 02:11:47 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43329>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43329





------- Additional Comments From Tom.Donovan@acm.org  2007-09-08 19:11 -------
It might be possible to confine the fix to Windows proc.c with enough
SetHandleInformation calls.  Since it's entirely a Windows problem, it seems
desirable to keep it out of the non-Windows code.

I've discovered a few things:

1. msvcr80 differs from msvcrt if si.hStdError contains INVALID_HANDLE_VALUE
but there is another valid stderr handle.  My orig patch didn't work with VS8
anyway because the new log.c cannot tolerate a missing stderr.  Previously VS8
builds had lots of failed apr calls in log.c because stderr was missing, but
they weren't visible (obviously...)  None were fatal.  The new httpd log.c has a
dup2 call (line 411) which breaks if stderr_log is null.

2. handle inheritance wasn't being reset correctly.  The 2nd arg to
SetHandleInformation is a mask, so the following doesn't reset the handle to
un-inheritable if stdin_reset is zero:

  SetHandleInformation(GetStdHandle(STD_INPUT_HANDLE),stdin_reset, stdin_reset);

SetHandleInformation is effectively a no-op when the second arg is zero.
That had me confused for a bit when the inheritance changed from call-to-call!  

3. There really is no good way to accommodate both the mpm_winnt child-creation
call (all 3 are inheritable but only stdin is passed in attr) and the various
combinations of inheritable (stderr can be changed by logging) handles and
supplied arguments in attr.  I came up with this rule:

* If 1-or-more attr handles are supplied and all 3 original handles are still
inheritable - keep them inheritable.  Otherwise, use INVALID_HANDLE_VALUE for
any missing handles in attr and suppress inheriting the original std* handles.

This does (I think) what you describe re: not allowing inherited handles in most
cases.  It does still allow the httpd child proc to inherit all 3 from its
parent, but once stdout becomes un-inheritable, no unwanted handles should ever
get to any later created processes.

A cmd.exe process would either need no handles in attr, or else three useable
handles.

I'll attach a patch which does all this.  I believe it works as expected for VC6
and VS8 builds on Win2k and WinXP with mod_perl and mod_fcgid (running
PHP-FastCGI or a stand-alone test FastCGI program).   I really should get a
clean copy of the 2.2.6-r2 source, apply the patch, and build & test it all
again - but I'll attach the patch now and add a comment if I find I overlooked
something.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message