Mailing-List: contact bugs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
From: bugzilla@apache.org
To: bugs@apr.apache.org
Subject: DO NOT REPLY [Bug 43329]  - apr_proc_create behavior change
In-Reply-To: <bug-43329-43213@http.issues.apache.org/bugzilla/>
Message-Id: <20070909021148.02FB1714191@brutus.apache.org>
Date: Sat,  8 Sep 2007 19:11:47 -0700 (PDT)

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