We had to turn a couple of 32-bit size arguments into 64-bit arguments
or size_t arguments (since otherwise we would have had to do it post
2.0.x-stable, and that would be worse).
Someday, when networks are far faster and people frequently want a
burst value greater than 2GB per tick, this will seem very forsightful
indeed.
For now, it breaks ABI, but not source. Fixes bug 3092096.
The old logic was both too eager to realign (it would move a whole
chain to save a byte) and too reluctant to realign (it would only
realign when data would fit into the misaligned portion, without
considering the space at the end of the chain).
The new logic matches that from evbuffer_expand_singlechain: it only
realigns a chain when not much data is to be moved, and there's a
bunch of space to be regained.
Spotted by Yan Lin.
The trigger for starting to read the first line of a request used to
be, "When data has arrived and we're looking for the first line."
But that's not good enough: if the entire next request gets read
into our bufev->inbuf while we're still processing the current
request, we'll never see any more data arrive, and so will never
process it.
So the fix is to make sure that whenever we hit evhttp_send_done, we
call evhttp_read_cb. We can't call it directly, though, since
evhttp_send_done is reachable from the user API, and evhttp_read_cb
can invoke user functions, and we don't want to force everyone to
have reentrant callbacks. So, we use a deferred_cb.
Found by Ivan Andropov. This is bug 3008344.
We were using evbuffer_add_buffer, which moved the entire buffer
contents. But if we had a valid content_length, we only wanted to
move up to the amount of data remaining in ntoread. Our bug would
make us put our ntoread in the negative, which would in turn make us
read all data until the connection closed.
Found by Denis Bilenko. Should fix bug 2963172.
This change has no effect on non-windows platforms, since those
either define off_t to 64-bits, or allow you to decide whether
it should be 64-bits yourself via some LARGEFILE-like macro.
On Windows, however, off_t is always 32-bit, so it's a bad choice
for "file size" or "file offset" values. Instead, I'm adding
an ev_off_t type, and using it in the one place where we used
off_t to mean "the size of a file" or "an offset into a file" in the
API.
This breaks ABI compatibility on Windows.
Previously, we chose "ADD" whenever old_events==new_events, (since
we expected the add to fail with EEXIST), or whenever old_events
was==0, and MOD otherwise (i.e., when old_events was nonzero and not
equal to new_events).
But now that we retry failed MOD events as ADD *and* failed ADD
events as MOD, the important thing is now to try to guess right the
largest amount of the time, since guessing right means we do only
one syscall, but guessing wrong means we do two.
When old_events is 0, ADD is probably right (unless we're hitting
the dup bug, when we'll fall back).
And when old_events is set and != new_events, MOD is almost
certainly right for the same reasons as before.
But when old_events is equal to new events, then MOD will work fine
unless we closed and reopened the fd, in which case we'll have to
fall back to the ADD case. (Redundant del/add pairs are more common
than closes for most use cases.)
This change lets us avoid calculating new_events, which ought to
save a little time in epoll.c
Current versions of the Linux kernel don't seem to remove the struct
epitem for a given (file,fd) combo when the fd is closed unless the
file itself is also completely closed. This means that if you do:
fd = dup(fd_orig);
add(fd);
close(fd);
dup2(fd_orig, fd);
add(fd);
you will get an EEXIST when you should have gotten a success. This
could cause warnings and dropped events when using dup and epoll.
The solution is pretty simple: when we get an EEXIST from
EPOLL_CTL_ADD, we retry with EPOLL_CTL_MOD.
Unit test included to demonstrate the bug.
Found due to the patient efforts of Gilad Benjamini; diagnosed with
help from Nicholas Marriott.
If an SSL connection becamse disabled or suspended before became open,
it could (under the right circumstances) wind up without ever getting
its write callback disabled.
The most correct fix is probably more subtle, and involves checking
all caseswhen a write callback is enabled or disabled. This fix is
more blunt, and explicitly checks whether the callback should have
been disabled at the end of the callback to prevent infinite looping.
Diagnosed with help from Sebastian Hahn
First, handle cases where we have %s in a tt_want or tt_assert.
Second, add tt_want_*_op that do a tt_*_op test, but do not exit the
test on failure.
We should push these upstream to tinytest some time.
NOTE: This is not the official release until I tag it. If you see
this commit, and you decide that Libevent 2.0.8-rc is now
finalized, you might get something besides 2.0.8-rc.
