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)
