"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."
Patch in question:
- Fix the case when failed evhttp_make_request() leaved request in the queue.
- http://levent.git.sourceforge.net/git/gitweb.cgi?p=levent/libevent;a=commit;h=0d6622e
The above patch introduces a failing assertion in
evhttp_connection_fail(). This happens because the patch defers the
assignment of the outstanding request to the evcon->requests list,
while evhttp_connection_fail() assumes that the request lies in the
list.
One scenario in which this can happen is when the request list is
empty and a connection is made to an unreachable host. The assertion
will then fail after bufferevent_socket_connect() errors out (with
ENETUNREACH in my case).
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.
This was a regression on 2.0.10-stable: clang was warning about
values that were unused (because event_debug wasn't using them unless
USE_DEBUG was defined). Found by Sebastian Hahn.
When compiling using clang (2.9 or lower) do not enable
-Wnormalized=id or -Woverride-init when --enable-gcc-warnings
or --enable-gcc-warnings-advisory is set as these options
are unsupported.
This commit is based on a patch for Tor
(git commit 56bdc844ba68ac0911efc7ad3398f1eafeaaac76 by Steven
Murdoch), Copyright (c) 2007-2011, The Tor Project, Inc.
First of all, it is totally okay to have an address end with .255,
depending on what your netmask is, so we shouldn't reject a local
address if it ends with .255.
Second, our check for ending with .255 was broken. So was our check
for class-d addresses.
Found by Dave Hart.
Imagine server side is buggy and miscalculates Content-Length: in the
reply. Data arriving in idle state shouldn't make us crash, instead we
can just reset the connection.
This patch fixes http://bugs.ntp.org/1844, works around
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=40401, by
improving the test for support of --gc-sections to run a program which
reads a file using stdio built with --gc-sections, instead of simply
link the binary. This catches the buggy linker as the garbage
collection removes a tag NetBSD uses to distinguish its own elf
binaries from Linux ones, causing it to treat conftest as a Linux
binary and run it with the wrong syscall table.
libevent/Makefile.am corrects a typo (thanks to Harlan for spotting it
once we realized make distcheck was broken when building the libevent
tearoff). The result was the include/ev*.h were not distributed nor
installed whether or not --disable-libevent-install was used. This
was introduced with the final round (3/3) of
--disable-libevent-install patch from me.
