This will allow to customize SO_RCVBUF/SO_SNDBUF for nameservers in this
evdns_base, you may want to adjust them if the kernel starts dropping
udp packages.
Before the fix:
$ regress --no-fork evbuffer/reserve_invalid_last_with_datap
evbuffer/empty_chain_expand: [err] ../buffer.c:2138: Assertion chain == buf->first failed in evbuffer_expand_fast_
Aborted (core dumped)
This is the a shorter version of test from the #806 (with some
comments).
User can define his own response method by calling
evhttp_set_ext_method_cmp() on the struct http, or
evhttp_connection_set_ext_method_cmp() on the connection.
We expose a new stucture `evhttp_ext_method` which is passed to the
callback if it's set. So any field can be modified, with some exceptions
(in evhttp_method_):
If the cmp function is set, it has the ability to modify method, and
flags. Other fields will be ignored. Flags returned are OR'd with the
current flags.
Based on changes to the #282 from: Mark Ellzey <socket@gmail.com>
Adds two new callbacks: "prepare" watchers, which fire immediately
before we poll for I/O, and "check" watchers, which fire immediately
after we finish polling and before we process events. This allows other
event loops to be embedded into libevent's, and enables certain
performance monitoring.
Closes: #710
To avoid possible confusion
But there is still one test that has some messages on windows:
main/methods
Because this test needs >1 of avaiable methods, otherwise it will warn.
- DNS_OPTION_NAMESERVERS_NO_DEFAULT
Do not "default" nameserver (i.e. "127.0.0.1:53") if there is no nameservers
in resolv.conf, (iff DNS_OPTION_NAMESERVERS is set)
- EVDNS_BASE_NAMESERVERS_NO_DEFAULT
If EVDNS_BASE_INITIALIZE_NAMESERVERS isset, do not add default
nameserver if there are no nameservers in resolv.conf (just set
DNS_OPTION_NAMESERVERS_NO_DEFAULT internally)
Fixes: #569
Due to regress linked with event and event_core (both of them includes
evthread.c) there will be two different evthread_id_fn_ variables under
mingw64:
evthread_id_fn_: &0x5294f20a8
evthread_id_fn_: &0x4ba0030a8
And because of this evthread_use_pthreads() can/will set one copy of
variables while evthread*() functions will access another, which will
break a lot of things (for example main/del_notify test).
Fixes: #792
This patch allows to change timeout for next events read/write/connect
separatelly, using new API:
- client:
evhttp_connection_set_connect_timeout_tv() -- for connect
evhttp_connection_set_read_timeout_tv() -- for read
evhttp_connection_set_write_timeout_tv() -- for write
- server:
evhttp_set_read_timeout_tv() -- for read
evhttp_set_write_timeout_tv() -- for write
It also changes a logic a little, before there was next fallbacks which
does not handled in new API:
- HTTP_CONNECT_TIMEOUT
- HTTP_WRITE_TIMEOUT
- HTTP_READ_TIMEOUT
And introduce another internal flag (EVHTTP_CON_TIMEOUT_ADJUSTED) that
will be used in evrpc, which adjust evhttp_connection timeout only if it
is not default.
Fixes: #692Fixes: #715
advance_last_with_data() adjusts evbuffer.last_with_datap, and if we
will have empty chain in the middle advance_last_with_data() will stop,
while it should not, since while empty chains is not regular thing they
can pops up in various places like, and while I did not look through all
of them the most tricky I would say is:
evbuffer_reverse_space()/evbuffer_commit_space()
evbuffer_add_reference()
Test case from:
https://github.com/envoyproxy/envoy/pull/6062Fixes: #778
v2: keep last_with_datap really last with data, i.e. update only if
chain has data in it
In case we have empty chain (chain that do not have any data, i.e. ->off
== 0) at the beginning of the buffer, and no more full chains to move to
the dst, we will skip moving of this empty chain, and hence
last_with_datap will not be adjusted, and things will be broken after.
Fix this by not relying on ->off, just count if we have something to
move that's it.
Test case from:
https://github.com/envoyproxy/envoy/pull/6062Fixes: #774
After we started to use kill() over raise() everything should work just
fine.
This reverts commit a86f89d333d870e6714bd28c695ba1774df3d7f5.
Fixed-in: 728c5dc1 ("Use kill() over raise() for raising the signal (fixes osx 10.14 with kqueue)")
Fixes: #747
On OSX 10.14+ the raise() uses pthread_kill() (verified with dtruss) and
by some reason signals that has been raised with pthread_kill() do not
received by kqueue EVFILT_SIGNAL.
While on OSX 10.11 the raise()/pthread_kill() uses plain kill() and
everything work just fine (linux also does the same, but instead of
kill() it uses tgkill())
Here is a simple reproducer that installs alarm to show that the signal
does not received by the kqueue backend:
https://gist.github.com/azat/73638b8e3b0fa563a20dadcca9e652a1
Refs: #747Fixes: #765
There can be tricky cases (that can be reproduced by reducing
SO_RCVBUF/SO_SNDBUF to 6144, on linux, and be aware, since linux doubles
this const), when there is still write event pending, although we read
enough.
This should be fixed in a more sophisticated way, but to backport the
patch, let's simply break the loop manually.
The ssl/bufferevent_wm originally failed on solaris.
windows has intptr_t instead of regular int.
Also tt_fd_op() had been introduced, since we cannot use tt_int_op() for
comparing fd, since it is not always int.
Next code will not work correctly under win x64:
evutil_socket_t very_long_pair_name[2];
int *pair = very_long_pair_name; // <-- accessing the second word of the first element
Because sizeof(evutil_socket_t) == sizeof(intptr_t) == 8
P.S. in the 5334762f another test had been fixed instead of the one that
really fails.
Fixes: 5334762f ("test/et/et: fix it by using appropriate type for the SOCKET (evutil_socket_t)")
Refs: #750
This patch mark testcases that only fail under travis-ci/appveyor with
TT_RETRIABLE, since otherwise there is too much noise, other issues
(like failures under vagrant boxes) would be investigated separatelly.
linux (from travis-ci only):
- http/cancel_by_host_no_ns
- http/cancel_by_host_inactive_server
- http/cancel_by_host_ns_timeout
- http/cancel_by_host_ns_timeout_inactive_server
- thread/conditions_simple
- util/monotonic_prc_precise
- util/usleep
- main/del_wait
vagrant/ubuntu box (this is the only exception):
- thread/no_events
win32 (from appveyor only):
- main/active_later
- main/persistent_active_timeout
And we should use TT_RETRIABLE over TT_OFF_BY_DEFAULT/TT_SKIP when it
make sense.
But there is still "test-ratelim__group_lim" left.
We have some tests that has false-positive due to real/CPU time bound,
but they are pretty generic and we do not want to skip them by default.
TT_RETRIABLE is the flag that will indicate tinytest to retry the test
in case of failure, use it to avoid next possible false-positives:
- real time-related
- CPU time-related
Since I guess it is better to see/grepping RETRYING messages over
ignoring completely failed builds.
No configuration switch for number of retries was done on purpose (only
3 retries and no more).
And this is how it looks BTW:
$ gcc ../test/tinytest_demo.c ../test/tinytest.c
$ ./a.out --verbose --no-fork
demo/timeout_retry
demo/timeout_retry:
FAIL ../test/tinytest_demo.c:201: assert(i != 1): 1 vs 1
[timeout_retry FAILED]
[RETRYING timeout_retry (3)]
demo/timeout_retry:
OK ../test/tinytest_demo.c:201: assert(i != 1): 2 vs 1
OK ../test/tinytest_demo.c:213: assert(t2-t1 >= 4): 5 vs 4
OK ../test/tinytest_demo.c:215: assert(t2-t1 <= 6): 5 vs 6
1 tests ok. (0 skipped)
Even after referenced patch there is still possible recursive callbacks
from evbuffer_drain(bev_input), i.e.:
wm_transfer() -> evbuffer_drain() -> wm_transfer()
inc(ctx->get)
But if we will increment ctx->get before drain that we will not add more
data to buffer.
Refs: 54c6fe3c ("regress_ssl: make ssl/bufferevent_wm_filter more fault-tolerance")
CI: https://ci.appveyor.com/project/nmathewson/libevent/build/job/f0rv299i71wnuxdq#L2546
Due to inplace callbacks (i.e. no BEV_OPT_DEFER_CALLBACKS) we cannot be
sure that wm_transfer() will not be called recursively and indeed it
still happens sometimes, and the referenced patch increase amount of
this times, especially for linux/poll.
Fixes: 66304a23cf748714159c988e78f35401c5352827 ("Fix
ssl/bufferevent_wm_filter when bev does not reach watermark on break")
EVHTTP_CON_READ_ON_WRITE_ERROR works only if an error already read from
the socket, but if we already got EPIPE on write we cannot read from the
socket anymore, and win32 does not guarantee that read will happens
before (although it happens from time to time).
In the referenced patch I just replaced callback with not expecting 417,
but like I already wrote, this is not always true (i.e. it is flacky).
Fixes: 3b581693ac1967f7f8d98491cb772a1b415eb4cd ("test/http:
read_on_write_error: fix it for win32")
For the ssl/bufferevent_wm* we have next configuration:
- payload_len = 1024
- wm_high = 5120
- limit = 40960
- to_read = 512
In this test we expect that with high watermark installed to "wm_high"
we will read "limit" bytes by reading "to_read" at a time, but adding
"payload_len" at a time (this "to_read"/"payload_len" limits is
installed to finally overflow watermark).
Once we read "limit" bytes we break, by disable EV_READ and reset
callbacks. Although this will not work if when we want to break we do
not reach watermark, this is because watermarks installs evbuffer
callback for the input buffer and if the watermark does not reached it
will enable EV_READ while be_openssl_enable() will read from the
underlying buffer (in case the openssl bufferevent created via
bufferevent_openssl_filter_new()) and call callback again (until it will
reach watermark or read al from the underlying buffer -- this is why it
stops in our caes).
And this is exactly what happened in win32, you can see this in the
following logs:
- win32 before:
OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 40960
OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 41472
OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 41984
OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
OK C:\vagrant\test\regress_ssl.c:829: wm_transfer-client(00DC2750): in: 4608, out: 0, got: 42496
OK C:\vagrant\test\regress_ssl.c:834: wm_transfer-client(00DC2750): break
- win32 after:
OK C:\vagrant\test\regress_ssl.c:821: wm_transfer-client(00FC26F0): break
OK C:\vagrant\test\regress_ssl.c:836: wm_transfer-client(00FC26F0): in: 4800, out: 0, got: 40960
- linux before:
OK ../test/regress_ssl.c:829: wm_transfer-client(0x55555566f5e0): in: 5120, out: 0, got: 40960
OK ../test/regress_ssl.c:834: wm_transfer-client(0x55555566f5e0): break
- linux after:
OK ../test/regress_ssl.c:821: wm_transfer-client(0x55555566f5e0): break
OK ../test/regress_ssl.c:836: wm_transfer-client(0x55555566f5e0): in: 5120, out: 0, got: 40960
(As you can see in linux case we already reach watermark hence it passed
before).
So fix the issue by breaking before draining.
But during fixing this I was thinking is this right? I.e. reading from
the be_openssl_enable(), maybe we should force deferred callbacks at
least?
Next tests uses fds without O_NONBLOCK flag
- main/free_active_base
- main/many_events
- et/et (has some other bits cleaned up by using TT_* flags and test
setup/cleanup callbacks)
And hence they will fail in debug mode (EVENT_DEBUG_MODE=):
Assertion flags & O_NONBLOCK failed in event_debug_assert_socket_nonblocking_
