Azat Khuzhin [Thu, 16 May 2019 07:25:50 +0000 (10:25 +0300)]
Merge branch 'evbuffer-fixes-806-v2'
* evbuffer-fixes-806-v2:
evbuffer: fix last_with_datap after prepend with empty chain
test: regression for evbuffer_expand_fast_() with invalid last_with_datap
test: cover adjusting of last_with_datap in evbuffer_prepend()
* issue-807-accept4-getnameinfo-AF_UNIX:
http-server: add usage/help dialog
http: avoid use of uninitialized value for AF_UNIX/AF_LOCAL sockaddr
http-server: add ability to bind to unix-socket
build: struct sockaddr_un detection (sys/un.h, afunix.h)
Dan Rosen [Wed, 17 Apr 2019 19:44:59 +0000 (15:44 -0400)]
evwatch: fix race condition
There was a race between event_base_loop and evwatch_new (adding a
prepare/check watcher while iterating over the watcher list). Only
release the mutex immediately before invoking each watcher callback,
and reacquire it immediately afterwards (same as is done for normal
event handlers).
Thomas Bernard [Fri, 8 Jan 2016 21:36:20 +0000 (13:36 -0800)]
Added http method extending
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>
Azat Khuzhin [Mon, 8 Apr 2019 19:27:33 +0000 (22:27 +0300)]
http: replace EVHTTP_REQ_UNKNOWN_ with 0
From the server perspective the evhttp_response_phrase_internal() should
not be called with 0 before this patch, it will be called with
EVHTTP_REQ_UNKNOWN_ hence this patch should not change behavior.
Fixes: 68eb526d7b ("http: add WebDAV methods support") Fixes: #789 Fixes: #796 Reported-by: Thomas Bernard <miniupnp@free.fr>
Dan Rosen [Tue, 26 Mar 2019 17:33:57 +0000 (13:33 -0400)]
evwatch: Add "prepare" and "check" watchers.
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.
Azat Khuzhin [Tue, 2 Apr 2019 20:25:08 +0000 (23:25 +0300)]
appveyor: check intermediate powershell commands exit codes and terminate early
Otherwise build errors will be ignored, i.e. if build fails but regress
binary exists (copied from artifacts) it will be runned instead of newly
compiled.
Azat Khuzhin [Sun, 31 Mar 2019 23:42:55 +0000 (02:42 +0300)]
Merge branch 'fix-uchex-warnings'
There is one more report that is false positive, see [1]:
"In bufferevent_openssl.c, pointer wm is dereferenced on line 871
before it is null checked on line 873."
Azat Khuzhin [Sun, 31 Mar 2019 23:41:17 +0000 (02:41 +0300)]
evdns: do not check server_req twice
Reported by µchex:
"In evdns.c, pointer server_req is null checked on line 1289 after it
is dereferenced above. Since server_req was already null checked above
on line 1243, there is no risk of crashing and the only bug is the
redundant null check (and indentation) on line 1289.
"
- 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)
Azat Khuzhin [Sun, 24 Mar 2019 22:40:46 +0000 (01:40 +0300)]
Link test/regress with event_core/event_extra over event
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).
Azat Khuzhin [Sat, 16 Mar 2019 14:41:09 +0000 (17:41 +0300)]
Merge branch 'buffer-read-size'
And after this patch set default evbuffer max read via bufferevent is
16K not 4K.
Here is some numbers for the single max read in evbuffer impact:
function client() { becat "$@" | pv > /dev/null; }
function server() { cat /dev/zero | becat -l "$@"; }
So as you can see without openssl 16K is faster then 40K/4K, while for
openssl 40K is still faster then 16K (I guess that this is due to with
openssl SSL_read() more at at time, while with plain we have some
allocations splits in evbuffer and maybe due to some buffer in openssl)
* buffer-read-size:
sample/becat: bufferevent cat, ncat/nc/telnet analog
Adjust evbuffer max read for bufferevents
Maximum evbuffer read configuration
Fix leaks in error path of the bufferevent_init_common_()
Azat Khuzhin [Tue, 12 Mar 2019 21:02:39 +0000 (00:02 +0300)]
cmake: sync warnings with autotools v2
By some reason gcc reports next error:
../http.c:3330:11: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
value = "";
Only under -Wwrite-strings, well this is logical, but this information
does not reflected in any documentation.
Follow-up: 8348b413 ("cmake: add various warning flags like autotools has")
Azat Khuzhin [Mon, 4 Mar 2019 03:53:42 +0000 (06:53 +0300)]
http: implement separate timeouts for read/write/connect phase
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.
Azat Khuzhin [Sun, 3 Mar 2019 15:58:57 +0000 (18:58 +0300)]
Merge branch 'evbuffer-empty-chain-handling'
* evbuffer-empty-chain-handling:
buffer: do not rely on ->off in advance_last_with_data()
buffer: fix evbuffer_remove_buffer() with empty chain in front
test: verify content of the buffer in evbuffer/remove_buffer_with_empty*
Azat Khuzhin [Sun, 3 Mar 2019 13:29:52 +0000 (16:29 +0300)]
buffer: do not rely on ->off in advance_last_with_data()
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/6062
Fixes: #778
v2: keep last_with_datap really last with data, i.e. update only if
chain has data in it
Azat Khuzhin [Sat, 2 Mar 2019 19:50:00 +0000 (22:50 +0300)]
buffer: fix evbuffer_remove_buffer() with empty chain in front
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/6062
Enji Cooper [Mon, 25 Feb 2019 19:59:15 +0000 (11:59 -0800)]
Define `_GNU_SOURCE` properly/consistently per autoconf
Although `_GNU_SOURCE` can be defined as an arbitrary #define per the
glibc docs [1], it's best to define it in a manner consistent with the way
that autoconf defines it, i.e., `1`.
While this shouldn't matter in most cases, it does when the headers from
other projects follow the poorly defined GNU convention implemented by
autoconf and are included after the libevent's util.h header. An example
failure with clang, similar to the failure I encountered, is as follows:
```
$ printf "#define _GNU_SOURCE\n#define _GNU_SOURCE 1" | clang -c -x c -
<stdin>:2:9: warning: '_GNU_SOURCE' macro redefined [-Wmacro-redefined]
^
<stdin>:1:9: note: previous definition is here
^
1 warning generated.
```
This happened when compiling python [2] with a stale homebrew util.h file from
libevent (which admittedly would not happen in a correct libevent install, as the
header should be installed under /usr/local/include/event2/util.h). However, if
both headers had been combined (which is more likely), it would have failed as
shown above.
Removing the ad hoc definition unbreaks compiling python's pyconfig.h.in header
when included after util.h from libevent.
Azat Khuzhin [Sun, 24 Feb 2019 14:07:18 +0000 (17:07 +0300)]
Use kill() over raise() for raising the signal (fixes osx 10.14 with kqueue)
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
Azat Khuzhin [Sun, 3 Feb 2019 15:47:14 +0000 (18:47 +0300)]
test/ssl/bufferevent_wm: explicitly break the loop once client/server received enough
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.
Azat Khuzhin [Tue, 29 Jan 2019 18:06:37 +0000 (21:06 +0300)]
test/et/et: use evutil_socket_t* over int* for pointer to the pair
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
Azat Khuzhin [Tue, 29 Jan 2019 07:54:39 +0000 (10:54 +0300)]
Merge branch 'win64-fixes'
* win64-fixes:
test/et/et: fix it by using appropriate type for the SOCKET (evutil_socket_t)
test/et/et: verify return codes
appveyor: switch to new VS/MinGW and x64
Azat Khuzhin [Sat, 24 Nov 2018 17:22:40 +0000 (20:22 +0300)]
appveyor: switch to new VS/MinGW and x64
The cache had been reseted with the following REST API requests:
DELETE https://ci.appveyor.com/api/projects/nmathewson/libevent/buildCache
DELETE https://ci.appveyor.com/api/projects/libevent/libevent/buildCache
DELETE https://ci.appveyor.com/api/projects/azat/libevent/buildCache