* 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*
(cherry picked from commit b69524c004fb68bcd9475e7aa61f5a7cdb45d304)
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.
1. http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
2. https://github.com/python/cpython/blob/master/configure.ac#L126Closes: #773 (cherry-picked)
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
(cherry picked from commit 5f87be42f0ae0126938624a1419a572607078217)
Since the migration request has been hanged for a while, let's switch it
for now without beauty API URL.
Fixes: #555
(cherry picked from commit 2fccb967c52e9f5373494df2773c684dee5ef973)
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
(cherry picked from commit 14eb903ba31987d24357abd05923677d194fedae)
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
(cherry picked from commit 728c5dc11f55b4ba5f518812833eab5a2cc3d550)
Currently, we do a lot of data munging with manual hex. This is ugly
and can lead to bugs. I defined the following:
_QR_MASK 0x8000U
_OP_MASK 0x7800U
_AA_MASK 0x0400U
_TC_MASK 0x0200U
_RD_MASK 0x0100U
_RA_MASK 0x0080U
_Z_MASK 0x0040U
_AD_MASK 0x0020U
_CD_MASK 0x0010U
_RCODE_MASK 0x000fU
So that we can more easily twiddle flags.
v2: make evdns flag masks unsigned literal
Closes: #756 (cherry-picked)
(cherry picked from commit fb134939160a4baad89fd4ab20c49afd617057e3)
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.
(cherry picked from commit ae9b285d2d7c9b898049072c157d50769d8014ea)
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.
(cherry picked from commit b29207dceee33832bb28ab103a833df6a2fd29d3)
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
(cherry picked from commit 0791a17204ff70bbea92520352a0c6e8d185fa4b)
* 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
(cherry picked from commit 97a3e7f5802ce1baa3c959905e312cab2bebf4bf)
* http-EVHTTP_CON_READ_ON_WRITE_ERROR-fixes-v2:
http: try to read existing data in buffer under EVHTTP_CON_READ_ON_WRITE_ERROR
test: add logging for http/read_on_write_error and rearrange code
http: do not call deferred readcb if readcb is not set
Refs: #749
(cherry picked from commit 7bfe93886d7fccad2d9a6c76cf47c47d3668f9d1)
* travis-ci-osx-fixes:
travis-ci/osx: switch to xcode 10.1, since 9.4 is not compatible with gcc-8
travis-ci/osx: install gcc and fix CC
(cherry picked from commit 5613bfb8dcd70ea1c89d04b550d9f97958cc48d2)
In 755fbf16c ("Add void* arguments to request_new and reply_new
evrpc hooks") this new functions had been introduced, but newer used,
what for? So let's use them.
(cherry picked from commit 99b231b0d875bc0814b0e4a940b6c9890d2a7754)
We should not attemp to establishe the connection if there is retry
timer active, since otherwise there will be a bug.
Imagine next situation:
con = evhttp_connection_base_new()
evhttp_connection_set_retries(con, 2)
req = evhttp_request_new()
evhttp_make_request(con, req, ...)
# failed during connecting, and timer for 2 second scheduler (retry_ev)
Then another request scheduled for this evcon:
evhttp_make_request(con, req, ...)
# got request from server,
# and now it tries to read the response from the server
# (req.kind == EVHTTP_RESPONSE)
#
# but at this point retry_ev scheduled,
# and it schedules the connect again,
# and after the connect will succeeed, it will pick request with
# EVHTTP_RESPONSE for sending and this is completelly wrong and will
# fail in evhttp_make_header_response() since there is no
# "http_server" for this evcon
This was a long standing issue, that I came across few years ago
firstly, bad only now I had time to dig into it (but right now it was
pretty simple, by limiting amount of CPU for the process and using rr
for debug to go back and forth).
(cherry picked from commit f3f7aa5afff2c0be4a1a299a1a7d0a64558abc23)
Could fail from time to time in travis-ci:
https://travis-ci.org/libevent/libevent/jobs/458554097#L1702
Follow-up-for: fe5b0719 ("Mark a lot of flacky tests with TT_RETRIABLE (for linux/win32 only)")
(cherry picked from commit 1d2ef90032bc842bc2e295ee4adce3408b6d85da)
