apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker pod.c
Date Fri, 21 Mar 2003 19:09:17 GMT
William A. Rowe, Jr. wrote:
> At 10:48 AM 3/21/2003, Jeff Trawick wrote:
> 
>>backtracking uses of fd 2 up through this time is somewhat funny
>>
>>it looks like
>>
>>a) we set the error log to file descriptor 2
>>
>>b) we close file descriptor 2 and set it to /dev/null via the freopen() in apr_proc_detach
>>
>>c) we close file descriptor 2 (because of cleanup registered around step a??)
> 
> 
> Bang.  We are dup2()ing that fd, and that fd didn't have a cleanup
> (in fact it was opened APR_FILE_NOCLOSE).
> 
> Attached is a patch that uses the logic
> 
>   apr_file_dup() always registers a cleanup, inherited for 0..2, 
>   otherwise not inherited by default.
> 
>   apr_file_dup2() registers the same cleanup the original open()
>   or the toggled apr_file_inherit_[un]set had indicated.  We still
>   don't trust the original cleanup, but register the 'proper' one
>   based on the desired behavior of that target apr_file_t.

I'm a bit nervous about the existing/new special handling for 
descriptors 0-2.

Why isn't the problem this:

Apache opened stderr from the wrong pool, or failed to open it again 
when the original pool for stderr was cleaned up; in other words, it was 
cleaned up because of a pool lifetime problem in the application, not 
because 0-2 inherently need to be handled in a different special way

(and maybe in addition: Apache should be able to tell apr_proc_detach() 
to leave stderr alone if it wants fd 2 to be unchanged across the detach)


Mime
View raw message