Sometimes DNS reply has nothing but query section. It does not look like
error, so it should be treated as NODATA with TTL=0 as soon as there is
no SOA record to deduce negative TTL from.
Instead of having a file segment born as one type and stay that way
forever, let them start out unmapped, but map themselves as needed
if they need to get written out on a non-drains_to_fd evbuffer.
The sendfile() implementation for evbuffer_add_file is potentially more
efficient, but it has a problem: you can only use it to send bytes over
a socket using sendfile(). If you are writing bytes via SSL_send() or
via a filter, or if you need to be able to inspect your buffer, it
doesn't work.
As an easy fix, this patch disables the sendfile-based implementation of
evbuffer_add_file on an evbuffer unless the user sets a new
EVBUFFER_FLAG_DRAINS_TO_FD flag on that evbuffer, indicating that the
evbuffer will not be inspected, but only written out via
evbuffer_write(), evbuffer_write_atmost(), or drained with stuff like
evbuffer_drain() or evbuffer_add_buffer(). This flag is off by
default, except for evbuffers used for output on bufferevent_socket.
In the future, it could be interesting to make a best-effort file
segment implementation that tries to send via sendfile, but mmaps on
demand. That's too much complexity for a stable release series, though.
Original post:
This post is in response to a posting last December on a Windows
regression fork failure ([Libevent-users] Re: Libevent 2.0.10-stable
is released by Dongsheng Song). I noticed the question was not
answered and I recently experienced the same error myself when
trying to run the Windows regression tests myself.
I checked the return status from the CreateProcess call and found it
was "file not found". This led me to look at the command-line I was
using which was .\regress in a Visual Studio 2008 command prompt
window. Windows could not find the file because it did not have the
.exe extension on the end. The code that builds the command should
be modified to ensure the extension is present.
Our evbuffer_strchr() function [which was only used for
search_eol(EOL_LF) could give incorrect results if it found its answer
in the first chunk but didn't start searching from the front of the
chunk.
Also, this patch adds unit tests for evbuffer_search_eol, particularly
in those cases that evbuffer_readln() tests didn't exercise.
Turns out that FreeBSD does _not_ give a ENETUNREACH error when
told to make a TCP socket to 255.255.255.255, but it is quite happy
to do so for 239.10.20.30. So that's what we'll do.
Found by Robert Ransom and Dave Hart.
