httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker pod.c
Date Fri, 21 Mar 2003 22:00:06 GMT
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.


>I'll buy that, except that I can't see the connection between apr_file_open_stderr() and


>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.


View raw message