If threads queue callbacks while event_process_deferred_callbacks is
running, the loop may spin long enough to significantly skew timers.
A unit test stressing this behavior is also in this commit.
This reverts commit fab50488fcb741884ccdfa7b83643eac3e5c9cbf.
The function was, on reflection, not important enough to break the feature
freeze, since it's trivial to build on your own.
If there is an event-config.h in include/event2 (either because we
screwed up packaging like in 2.0.6-rc or because we previously tried
building with mingw and we didn't make distclean in the middle), we
want MSVC to find the one one in WIN32-Code/include/event2 first.
Found by Gilad Benjamini.
When we freed a bufferevent that was in a rate-limiting group and
blocked on IO, the process of freeing it caused it to get removed
from the group. But removing the bufferevent from the group made
its limits get removed, which could make it get un-suspended and in
turn cause its events to get re-added. Since we would then
immediately _free_ the events, this would result in dangling
pointers.
Fixes bug 3041007.
If you were to enable USE_DEBUG and slog through all 700+ MB of
debugging output, you'd find that one of the unit tests failed,
since it tested the debug logging code, but the string it expected
and the string it logged differed by a tab vs 2 spaces.
If the rate limit was low enough, then the echo_conns wouldn't finish
inside the 300 msec we allowed for them to close. Instead, count the
number of connections we have, and keep waiting until they are all
closed.
To be fair, when char can be signed, if toupper doesn't take negative
characters, toupper(char) is a very bad idea. So let's just use the
nice safe EVUTIL_TOUPPER instead. (It explicitly only upcases ASCII,
but we only use it for identifiers that we know to be ASCII anyway).
The bufferevent_connect_hostname test was specifying AF_INET, but the
gethostbyname test we were using to see what error to expect was using
PF_UNSPEC, leading to possible divergence of results.
Eventually test-changelist should expand to try more cases, maybe
query the status of the actual changelist somehow, and integrate it
with the rest of the unit tests.
Also, add test-changelist to gitignore.
I'm running a fairly simple bit of test code using libevent2 with epoll and
openssl bufferevents and I've run into a 100% cpu usage problem.
Looking into it 100% usage was caused by epoll_wait constantly
returning write events on the openssl socket when it shouldn't really have
been looking for write events at all (N_ACTIVE_CALLBACKS() was returning 0
also).
Looking a bit deeper eventbuffer_openssl socket seems to be requesting
that the EV_WRITE event be removed when it should, but the event isn't
actually being removed from epoll.
Continuing to follow this I think I've found a bug in
event_changelist_del.
For evpoll event_del calls event_changelist_del which caches the change
which is then actioned later when evpoll_dispatch is called.
In event_changlist_del there is a check so that if the currently changed
action is an add then the cached action is changed to a no-op rather than a
delete (which makes sense). The problem arises if there are more than
two add or delete operations between calls to dispatch, in this case it's
possible that the delete is turned into a no-op when it shouldn't have
been.
For example starting with the event on, a delete followed by an add and
then another delete results in a no-op when it should have been a delete (I
added a fair bit of debug output that seems to confirm this behaviour).
I've applied a small change that checks the original old_event stored with
the change and only converts the delete to a no-op if the event isn't on in
old_event. This seems to have fixed my problem.
On all the backends on this little mac laptop, that behavior is to
report a remote socket close as both EV_READ and EV_WRITE.
Historically, we had problem for some of these behaviors on some
backends, so let's make sure that such behaviors don't come back.
The default behavior of test.sh was to suppress all output from
test/regress, and say nothing but OKAY or FAILED. This wasn't so good
for getting bugs reported, since lots of people didn't know to set
TEST_OUTPUT_FILE, or re-run ./test/regress on its own.
Now, when you don't specify an output file for test.sh, it runs
regress with the --quiet option. This option makes the unit tests
only print output on failure, which is what we probably wanted.
The new options let you specify a maximum deviation of bandwidth used
from expected bandwidth used, and make test-ratelim.c exit with a
nonzero status when those deviations are violated.
This patch also adds a test-ratelim.sh script to run test-ratelim with
a few sensible options for testing.
This attribute tells gcc (and anything else that understands gcc
attributes) that the functions will never return control, and helps
the optimizer a little. With luck, it will also tell
less-than-full-program dataflow analysis tools that they don't need to
worry about any code path that involves calling one of these functions
and then returning.
This patch also forces event_exit() to always exit, no matter what the
user-supplied fatal_callback does. This means that the old unit tests
for the event_err* functions don't work any more, since they assume it
is safe to call event_err* if you've given it a bogus fatal_callback
that doesn't exit. Instead, we have to make the unit tests fork
before calling event_err(), and have the main unit test process wait
for the event_err() test to exit with a sane exit code. On unix,
that's trivial. On windows, let's not bother and just assume that
event_err* works.
It turns out that in all conformant shells, "unset FOO" removes FOO
both from the shell's variables and from the exported environment.
(I've tested this on msys, opensolaris, linux, osx, and freebsd.)
And in nearly every shell I can find, "unset FOO; export FOO" does
the same as unset FOO... except in my FreeBSD VM, where the "export
FOO" sets the exported value of FOO equal to "". This broke test.sh
for us.
The fix is simple: remove the needless exports!
This required:
- Adding another WIN32 section in test.sh
- not running "touch /dev/null"
- calling WSAStartup in all the test binaries
- Fixing a dumb windows-only bug in test-time.c
Previously, the be5_outcome field for the dns error would be set to
something dependent on our system resolver. It turns out that you
can't rely on nameservers to really give you an NEXIST answer for
xyz.example.com nowadays: too many of them are annoyingly broken and
like to redirect you to their locked-in portals. This patch changes
the bufferevent_connect_hostname test so that it makes sure that the
dns_error of be5_outcome is "whatever you would get from resolving
the target hostname"
Importantly, we don't actually want to call evbuffer_write() when
the buffer is empty. This makes it an error to ever get a -1 return
value from evbuffer_add_file(), which makes it safe for us to test
the return value.
