At 02:36 PM 3/21/2003, Jeff Trawick wrote:
>>>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
>>
>>Because we agreed that the API would support APR_FILE_NOCLOSE and
>>that is how apr_file_stderr_open() works.
>
>you mean APR_FILE_NOCLEANUP?
right...
>I'll buy that, except that I can't see the connection between apr_file_open_stderr()
>and APR_FILE_NOCLEANUP
simple;
>APR_DECLARE(apr_status_t) apr_file_open_stderr(apr_file_t **thefile,
> apr_pool_t *pool)
>{
> int fd = STDERR_FILENO;
>
> return apr_os_file_put(thefile, &fd, 0, pool);
>}
The bottom line? apr_os_file_put has always stuffed an fd into a handle,
and registered no cleanup. Our change to dup2() began registering
a cleanup - which is the side effect you were watching this morning.
So it's impossible to toggle the APR_INHERIT bit (which flips between
a child cleanup of apr_pool_cleanup_null and apr_unix_file_cleanup.)
If you look at the patch to apr_os_file_put file_io/unix/open.c rev 1.111
you will see that we now reflect in the ->flags that no cleanup has
been registered (APR_FILE_NOCLEANUP).
Now I foresaw the apr_os_file_put side of the coin, but we need to start
respecting those two bits in apr_file_dup2. We still can't be sure that
the old cleanup is valid (did the user call apr_file_close() before dup2?
if so the cleanup is now broke), but we sure can pre-kill the old cleanup
and then register the appropriate cleanup based on the ->flags value.
Please let me know if the patch picks back up the correct behavior.
Bill
