Am 03.12.2013 00:37, schrieb William A. Rowe Jr.:
On Mon, 02 Dec 2013 01:34:58 +0100
Branko Čibej <[email protected]> wrote:
On 02.12.2013 01:29, Eric Covener wrote:
I am looking at a httpd bug that causes a hang on windows but
succeeds on unix.
It seems that (short) files are opened w/ buffering, read,
apr_file_closed, and read again [succesfully on unix]
On Unix, they sare satisfied out of the buffer. file->fileset is
-1. On Windows, the destroyed apr_thread_mutex causes a hang.
Is reading from the closed file on the extreme bogus end of the
spectrum as I suspect and just getting lucky on the unix case?
I'd certainly call a successful read from a closed file a bug.
Should they blow up in 2.0 during a read if they've been closed?
Dunno ... my gut feeling in cases like this is to just leave it be.
Developers should have some fun finding heisenbugs, too. :)
If we fix this, it needs to be minimal impact. Zero'ing out the
buffer on close seems like the lowest cpu impact.
A minimal impact and IMHO the correct fix is to return an error in
buffered I/O if the file was closed.
An application should not call a read or write function on a closed
file. If it does its a bug and it should be notified about that fact.
Thus I would propose the following fix in apr_file_read() and any other
read/write function which uses buffered I/O:
APR_DECLARE(apr_status_t) apr_file_read(apr_file_t *thefile, void *buf,
apr_size_t *nbytes)
{
apr_ssize_t rv;
apr_size_t bytes_read;
+ if (thefile->filedes < 0) {
+ return APR_EBADF;
+ }
if (*nbytes <= 0) {
*nbytes = 0;
return APR_SUCCESS;
}
Regards,
Stefan
