As originally written, the test would only pass if the accept()
callbacks for the evconnlistener were all invoked before the last of
the CONNECTED/ERROR callbacks for the connecting/resolving bufferevent
had its call to event_base_loopexit() complete. But this was only
accidentally true in 2.0, and might not be true at all in 2.1 where
we schedule event_base_once() callbacks more aggressively.
Found by Sebastian Hahn.
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.
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.
Define WIN32_LEAN_AND_MEAN, so that windows.h does not bring in
winsock.h which in turn makes it impossible to #include <winsock2.h>
(at least with MSVC)
"I'm not sure if you'll like my use of the limited broadcast address
for simulating an ENETUNREACH error with a TCP connection, but it's
the best that I could think of. Basically, we want to trigger a
non-EINPROGRESS error in evutil_socket_connect() immediately at the
connect() in order to bring about the assertion in the
evhttp_connection_fail() error handling code."
I took this fix from Tor (commit 1a52e39c22d5, author Nick Mathewson,
Copyright (c) 2007-2011, The Tor Project, Inc.) and adapted it slightly
for libevent.
Apparently, kevent fails gracefully if there is not enough space in its
output events array to report every _event_... but it just dies and returns
-1 if there is not enough space to report every _error_.
There are a couple of possible fixes here. One would to handle -1
returns from kevent better by re-growing the array and retrying... but
that seems a little error prone. Instead, I'm just going to say that
the events array must be large enough to handle all the errors.
This patch also adds a unit test designed to make sure that our
many-events-out code works even if not all the events are added at
once.
