[ Upstream commit f7bc1337977553f5f966f13840a5f7feba2d0bd5 ]
- When socket() failed in bufferevent_socket_connect() , the event
callback should be called also in
bufferevent_socket_connect_hostname(). eg. when use
bufferevent_socket_connect_hostname() to resolve and connect an IP
address but process have a smaller ulimit open files, socket() fails
always but caller is not notified.
- When make socket nonblocking failed in bufferevent_socket_connect(),
free the fd.
- Make bufferevent_socket_connect()'s behavior more consistent: function
return error then no callback, function return ok then error passed by
event callback.
Backport-for: 2.0
Refs: #597
Refs: #599
Refs: #600Closes: #599 (cherry-pick)
[ Upstream commit b77d3e787b5522380c65838d3baa22e661eff0db ]
After two or more events have been registered for the same file
descriptor using EV_ET, if one of the events is deleted, then the
epoll_ctl() call issued by libevent drops the EPOLLET flag resulting in
level triggered notifications.
[ azat: test for EV_ET for EPOLL_CTL_MOD too, for libevent 2.0 ]
Fixes: #636
[ Upstream commit c83f3333a34251275c38878e9667c904a485ac6d ]
config.cache is generated when you run `./configure -C`.
test-driver comes from newer autotools.
[ Upstream commit 9b5a527f5bf898250a797dde59cadb4f64e8967a ]
This fixes assertion failures in cases where epoll() fails with EBADF
-- the root cause for which is as of yet unknown. It seems something
(OpenSSL?) is closing the file descriptor under our feet.
From [1]:
regress_buffer.c:742:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < 1 << 16; ++i) {
^
regress_buffer.c:742:3: note: use option -std=c99 or -std=gnu99 to compile your code
regress_buffer.c:787:23: error: conflicting types for ‘bufread’
for (int n = toread, bufread = toread;
^
regress_buffer.c:717:51: note: previous definition of ‘bufread’ was here
size_t datalen = strlen(data), toread = datalen, bufread = 0;
^
regress_buffer.c:787:2: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int n = toread, bufread = toread;
^
[1]: https://travis-ci.org/azat/libevent/jobs/445501665
[ Upstream commit df6f99e5 ]
[ Fixes: #377 ]
EV_ERROR is a bit in struct kevent::flags. Other bits may be set too.
Actually we have osx builds on travis-ci, but it uses osx 10.9.5, and we don't
have warnings there, since I guess that there is no OR'ing with previous flag
in case of error, while in 10.12 there is OR.
Fixes: #377Fixes: #376
Link: https://crbug.com/626534
Link: https://travis-ci.org/libevent/libevent/jobs/141033429
[ Upstream commit 6ac8e775 ]
[ Fixes: #262 ]
Between start (setting "started_at") and comparing the time when
timeouts triggered with the start (test_timeval_diff_eq), there is too
much various things that can introduce extra delays and eventually could
fail the test on machine with shortage of CPU.
And this is exactly what happend on:
- travis-ci
- #262
Here is a simple reproducer that I came up with for this issue:
docker run --cpus=0.01 -e LD_LIBRARY_PATH=$PWD/lib -e PATH=/usr/bin:/bin:$PWD/bin -v $PWD:$PWD --rm -it debian:testing regress --no-fork --verbose bufferevent/bufferevent_timeout
Under limited CPU (see reproducer) the test almost always has problems
with that "write_timeout_at" exceed default timeval diff tolerance
(test_timeval_diff_eq() has 50 tolerance), i.e.:
FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 101 vs 50
But under some setup write timeout can even not triggered, and the
reason for this is that we write to the bufferevent 1024*1024 bytes, and
hence if evbuffer_write_iovec() will has some delay after writev() and
not send more then one vector at a time [1], it is pretty simple to
trigger, i.e.:
FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 1540155888478 vs 50
[1]: https://gist.github.com/azat/b72773dfe7549fed865d439e03de05c1
So this patch just send static small payload for all cases (plus a few
more asserts added).
The outcome of this patch is that all regression tests passed on
travis-ci for linux box [2]. While before it fails almost always [3].
Also reproducer with CPU limiting via docker also survive some
iterations (and strictly speaking it should has less CPU then travis-ci
workers I guess).
[2]: https://travis-ci.org/azat/libevent/builds/444391481
[3]: https://travis-ci.org/libevent/libevent/builds/444336505
Bunch of fixes for evbuffer_add_file().
* evbuffer_add_file-2.0-fixes:
Cover evbuffer_add_file() with offset
evbuffer_add_file: do not use evbuffer_remove(), instead calc offset for mmap()
evbuffer_add_file: munmap() correct size on mmap() failure
evbuffer_add_file: fix endless loop when file does not have such amount of data
Fixes: #306
@ellzey:
"when evbuffer_add_file is called and mmap is used, if the offset
argument is >0, a mistake happens: add_file removes "offset" byts
from the front of the evbuffer.
So that means any data that was previously on the buffer is trimmed
off by "offset" bytes. Whoops."
And even more when offset>0, evbuffer_add_file() still maps whole file,
let's calc appropriate offset and length.
And here is the wrong fix:
afca576a05
* origin/pr/338:
evbuffer_add: Use last_with_datap if set, not last.
Use the free-trailing-chains function in evbuffer_insert_chain too
test/regress: add tests for evbuffer_add() breakage on empty last chain
Fixes: #335
evbuffer_add() would always put data in the last chain, even if there
was available space in a previous chain, and in doing so it also
failed to update last_with_datap, causing subsequent calls to other
functions that do look at last_with_datap to add data in the middle
of the evbuffer instead of at the end.
Fixes the evbuffer_add() part of issue #335, and the evbuffer/add2 and
evbuffer/add3 tests, and also prevents wasting space available in the
chain pointed to by last_with_datap.
The evbuffer/add* tests currenly break on 2.0.21, 2.0.22 and 2.1 HEAD
due to issue #335. The evbuffer/reference2 test breaks on 2.0.21 and
2.0.22 due to commit b18c04dd not being applied.
This patchset is just a backport from upstream (with minor fixes to function
names in tests) of 2ecd894725e167dcc1f22f9292f98e41299df6cc ("Merge pull
request #39 from azat/fix-http-for-ipv6")
* fix-http-for-ipv6-backport-for-2.0:
Add regress test ipv6_for_domain.
Fix ipv6 support for http. When URL contain domain, not IP address.
Fixes#287
Written for commit 71e709c7829275a594f767b27468b1b52e8b5bb9.
Fix ipv6 support for http. When URL contain domain, not IP address.
backporting to 2.0: fix conflicts with the name of the main function --
_http_connection_test().
Before this patch socket created before domain was resolved, and it
always create with AF_INET (ipv4), but we must create socket only after
domain was resolved to understad which protocol family have domain
address.
Thank to Patrick Pelletier, who found this bug.
For this fix, we need to make sure that passing too-large inputs to
the evbuffer functions can't make us do bad things with the heap.
Also, lower the maximum chunk size to the lower of off_t, size_t maximum.
This is necessary since otherwise we could get into an infinite loop
if we make a chunk that 'misalign' cannot index into.
There is a race between manual event_active and natural event activation. If both happen at the same time on the same FD, they would both be protected by the same event base lock except for 1 LoC where the fields of struct event are read without any kind of lock. This commit does those reads into local variables inside the lock and then invokes the callback with those local arguments outside the lock. In 2.0-stable, none of this is inside the lock; in HEAD, only the callback is read inside the lock. This gets the callback and all 3 arguments inside the lock before calling it outside the lock.
