Fix undefined behaviour and application crash that might take
place in some rare cases after calling evdns_base_free when
there are requests in the waiting queue.
Current cleanup procedure in evdns_base_free_and_unlock
function includes 2 steps:
1. Finish all inflight requests.
2. Finish all waiting requests.
During the first step we iterate over each list in req_heads
structure and finish all requests in these lists. With current
logic finishing an inflight request (function request_finished)
removes it from the inflight requests container and forces
a wating connection to be sent (by calling
evdns_requests_pump_waiting_queue). When these new requests are
sent it is possible that they will be inserted to the list in
req_heads that we've already cleaned.
So in some cases container of the inflight requests is not empty
after this procedure and some requests are not finished and
deleted. When timeouts for these requests expire
evdns_request_timeout_callback is called but corresponding
evdns_base has been already deleted which causes undefined
behaviour and possible applicaton crash.
It is interesting to note that in old versions of libevent such
situation was not possible. This bug was introduced by the commit
14f84bbdc77d90b1d936076661443cdbf516c593. Before this commit
nameservers were deleted before finishing the requests. Therefore
it was not possible that requests from the waiting queue be sent
while we finish the inflight requests.
(cherry picked from commit 4da9f87ccbe71edb3b3aaf74b8b64d7e9c41dcaf)
supposing if base is null, EVBASE_ACQUIRE_LOCK and EVBASE_RELEASE_LOCK
would get a coredump, so we add a guard for protection.
Signed-off-by: chenguolong <cgl.chenguolong@huawei.com>
(cherry picked from commit 968bbd5c918568eb95b493af05c464ddfc36671b)
For OSX the socket should be closed, otherwise the "connection refused"
will not be triggered.
And freebsd can return error from the connect().
(cherry picked from commit 30fe125041ab38045487bd3af60d2f564dffc81c)
Moves the thread into real-time scheduling class, as recommended in [1], it
fixes the separate test provided by @ygj6 [2] everywhere (github actions,
travis-ci, appveyor) under osx.
[1]: https://developer.apple.com/library/archive/technotes/tn2169/_index.html
[2]: dde1a6e4d0
Although even after this changes the following time-related tests failed
on travis-ci:
- no_events
- del_wait
But anyway I guess #940 can be closed, since this fixes the issue in common.
* osx-clock:
test: Use THREAD_* wrappers in del_notify/del_wait
test: move threads created with THREAD_START() to realtime scheduling class too
test: put thread into real time scheduling class on osx for better latencies
Closes: #940
(cherry picked from commit a6f81aa45455c8afb69980f7026a0e706f4f9387)
After this patchset http-connect works with pproxy [1]:
$ pproxy -l http://:8000/ -vvv &
$ http-connect //127.1:8000 http://kernel.org:80/
[1]: https://pypi.org/project/pproxy/
* http-connect:
http-connect: do not check connection on GET cb
http-connect: set Host header (for CONNECT and GET) (like curl)
http-connect: cleanup and helpers
http: do not close connection for CONNECT
http: do not assume body for CONNECT
Fixes: #946
(cherry picked from commit 462f2e97660cc2b6af563ab631050a83c3e0935b)
Use the following for openssl 1.1+:
- X509_getm_notBefore over X509_get_notBefore
- X509_getm_notAfter over X509_get_notAfter
- use OPENSSL_VERSION_NUMBER over SSLeay()
- add missing headers
Refs: openssl/openssl@0b7347effe
(cherry picked from commit 08981f8d752ad23e21887b42944783e843b2e281)
This will allow overriding them in parent cmake rules, i.e. if libevent
is used via add_subdirectory().
Closes: #931
(cherry picked from commit 8f13c170cf6e9a02dec410b967884ec5e08947ab)
Do not do any assumptions on the error for the EMFILE from
getaddrinfo(), expect just any error.
Fixes: #924
(cherry picked from commit 4436287d1247fb2e9c80560debf852a94657e485)
Don't override any -DCMAKE_MODULE_PATH= passed from CLI
to eg. test custom Platform/ support.
(cherry picked from commit 84affc1837a727640f46eff2723c1364d2cd1695)
It had been deprecated for a long time (AFAIK), but since
glibc-2.29.9000-309-g744e829637 it produces a #warning
(cherry picked from commit b9b9f19058dc04b7ad4d079a38f6b86c0e7b1072)
kevent::udata was switched from intptr_t to void*.
Handle both cases with the GCC extension typeof().
(cherry picked from commit 72e6eff0251bffec72e0b8b2cedf72f173c8b9e9)
The CMAKE_C_FLAGS_DEBUG, CMAKE_C_FLAGS_RELEASE, CMAKE_C_FLAGS_MINSIZEREL
and CMAKE_C_FLAGS_RELWITHDEBINFO options are correctly and deliberately
toggled to use the libcmt (/MT) flag options in place of the usual
msvcrt (/MD) options, but this isn't necessarily desired by the user.
The default choice can be overriden with the EVENT__MSVC_STATIC_RUNTIME
cmake option.
However, the /MD flag that is the choice of CMake only enters into
play for the four types of builds above. If the user introduces another
CMAKE_BUILD_TYPE, the base CMAKE_C_FLAGS must not be manipulated, as
that value (and the CMAKE_C_FLAGS_{custom} value) have been explicitly
chosen by the user/developer deploying this library, and the mismatch
between these flags in different dependencies results in link errors.
The CMake build schema itself doesn't place an /MD flag in CMAKE_BUILD_TYPE
so any /M compile option in that variable needs to be retained.
Signed-off-by: William Rowe <wrowe@pivotal.io>
Signed-off-by: Yechiel Kalmenson <ykalmenson@pivotal.io>
(cherry picked from commit af4b07a55cc0ff0298cbd26c87b3f6a08f84c394)
* upstream/pr/899:
improve the description of parameter to evbuffer_read()
regress_buffer: improve testcase for evbuffer_freeze()
(cherry picked from commit a977d6963611c729b75108d31bf74718b7b3e06d)
if evbuffer_add_file_segment() fails it returns -1, so we should call
evbuffer_file_segment_free() only on error, and this -1 not 0.
Fixes: 6a81b1f5 ("Avoid double-free on error in evbuffer_add_file. Found by coverity.")
Backport-to: 2.1
(cherry picked from commit 4727150a54e21725f0ef4f43ca5028cc6f353664)
Since sysctl() is deprecated for a long-long time, according to
sysctl(2):
Since Linux 2.6.24, uses of this system call result in warnings in the kernel log.
Fixes: #890
Suggested-by: Pierce Lopez
(cherry picked from commit 86f55b0420f864b518475f781ce7a3c619180b12)
- AC_PROG_SED
- AC_USE_SYSTEM_EXTENSIONS
- AC_TRY_COMPILE -> AC_COMPILE_IFELSE
- AC_TRY_RUN -> AC_RUN_IFELSE
...
Also use:
- AC_CONFIG_AUX_DIR
Refs: #870
Fixes: 3f09e923 ("Change the minimum version of automake to 1.13 and autoconf to 2.67")
(cherry picked from commit 13b8fc39fd4000de2c836b0acdc52ae5b4c757c7)
Thinking about this more and realizing that this was a mistake, so
should be reverted.
In a nut shell I guess most of the apps calls event_reinit() from the
loop (see [1] for example), and this should be totally fine (the bit
with the signals [2] handled in event_reinit() gracefully)
[1]: https://archives.seul.org/libevent/users/Aug-2019/msg00009.html
[2]: https://github.com/libevent/libevent/pull/833#issuecomment-501834453
This reverts commit 497ef904d544ac51de43934549dbeccce8e6e8f8.
Reported-by: mikulas@twibright.com
Backport-to: 2.1
(cherry picked from commit ddacaef59ab6808a0801007d0a681f2415af4871)
