The `cmake_minimum_required(VERSION 3.10)` command implicitly sets the
following policies to NEW by default:
- CMP0042 (introduced in CMake 3.0)
- CMP0054 (introduced in CMake 3.1)
- CMP0068 (introduced in CMake 3.9)
The reason it is not possible for libevent is that:
a) it is unlikely to have 1610612741 elements
b) growing is done incrementally (i.e. only internally by HT_INSERT) and
in this case the UB is not possible
Fixes: https://github.com/libevent/libevent/issues/1312
This patch adds functionality to pass a pre-existing connection
as a bufferevent to `evhttp_connection_base_bufferevent_reuse_new`.
When the bufferevent has an existing fd, the evcon starts
in state `EVCON_IDLE` so that requests can be made immediately.
Signed-off-by: Kirill Rodriguez <theoden8@tutamail.com>
Signed-off-by: Kirill Rodriguez <theoden8@tutamail.com>
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
Co-authored-by: Azat Khuzhin <a3at.mail@gmail.com>
When using libevent on the Windows platform in an IPv6 environment, I found that libevent could not read the DNS server address for IPv6 addresses during DNS initialization, resulting in constant DNS resolution failures. Then, on MSDN, I discovered that the GetNetworkParams interface does not support obtaining IPv6 addresses, and they provided another interface, GetAdaptersAddresses, to obtain both IPv4 and IPv6 addresses. Therefore, I replaced the GetNetworkParams interface with the GetAdaptersAddresses interface. Please review whether this modification can be merged into the master branch.
Reference MSDN documentation:
https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getnetworkparamshttps://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses
Co-authored-by: alphacheng <alphacheng@tencent.com>
Co-authored-by: Azat Khuzhin <azat@libevent.org>
Co-authored-by: Azat Khuzhin <a3at.mail@gmail.com>
Even though the initial request was about Android, it is not only about
it, but it could be the case for Linux as well (so as Apple M1/...
chips)
And this should not affect anything, since this is just ELFs
Fixes: https://github.com/libevent/libevent/issues/1708
By some reason even after first ALRM signal received and event loop
returned it is possible to recieve an ALRM one more time (at least one):
% yes signal/simple_signal.. | head -n 1000 | xargs -I{} -P10 sh -c 'EVENT_DEBUG_LOGGING_ALL= bin/regress --timeout 0 --verbose {} >& /tmp/test.$SECONDS.$RANDOM.log'
% cat /tmp/test.0.18384.log
signal/simple_signal: [forking] [debug] event_add: event: 0x16d70f368 (fd 14), call 0x102704ae8
[debug] evsig_ensure_saved_: evsignal (14) >= sh_old_max (0), resizing
OK /Users/ec2-user/libevent/test/regress.c:1086: assert(setitimer(ITIMER_REAL, &itv, NULL) == 0): 0 vs 0[debug] kq_dispatch: kevent reports 1
[debug] event_active: 0x16d70f368 (fd 14), res 8, callback 0x102704ae8
[debug] event_process_active: event: 0x16d70f368, call 0x102704ae8
[debug] event_del: 0x16d70f368 (fd 14), callback 0x102704ae8
[debug] event_base_loop: no events registered.
FAIL /Users/ec2-user/libevent/test/regress.c:1062: ALRM received not from event loop![debug] event_del: 0x16d70f368 (fd 14), callback 0x102704ae8
[debug] event_base_free_: 0 events freed
signal/simple_signal: exited with 0 (0)
[FAILED signal/simple_signal (0 retries)]
signal/simple_signal_re_order: [forking] [debug] event_add: event: 0x16d70f368 (fd 14), call 0x102704ae8
[debug] evsig_ensure_saved_: evsignal (14) >= sh_old_max (0), resizing
[debug] event_del: 0x16d70f368 (fd 14), callback 0x102704ae8
[debug] event_add: event: 0x16d70f368 (fd 14), call 0x102704ae8
OK /Users/ec2-user/libevent/test/regress.c:1086: assert(setitimer(ITIMER_REAL, &itv, NULL) == 0): 0 vs 0[debug] kq_dispatch: kevent reports 1
[debug] event_active: 0x16d70f368 (fd 14), res 8, callback 0x102704ae8
[debug] event_process_active: event: 0x16d70f368, call 0x102704ae8
[debug] event_del: 0x16d70f368 (fd 14), callback 0x102704ae8
[debug] event_base_loop: no events registered.
[debug] event_del: 0x16d70f368 (fd 14), callback 0x102704ae8
[debug] event_base_free_: 0 events freed
signal/simple_signal_re_order: exited with 0 (0)
1/2 TESTS FAILED. (0 skipped)
Also note, that the problem not only when I run two tests, but only one
as well:
% bin/regress --timeout 0 --repeat 1000 --verbose --no-fork signal/simple_signal >/tmp/test2.log 2>&1
signal/simple_signal:
OK /Users/ec2-user/libevent/test/regress.c:1086: assert(setitimer(ITIMER_REAL, &itv, NULL) == 0): 0 vs 0
signal/simple_signal:
OK /Users/ec2-user/libevent/test/regress.c:1086: assert(setitimer(ITIMER_REAL, &itv, NULL) == 0): 0 vs 0
FAIL /Users/ec2-user/libevent/test/regress.c:1062: ALRM received not from event loop!
I've tried to run under "ktrace trace -Ss -f C4,S0x010c -c" but of
course it does not fails under it (dtruss by some reason did not work
for me).
P.S. Also remove one TT_RETRIABLE for one test, since only setitimer()
causes this.
When calling the user callback after a DNS resolution on error, make
sure to send back the query type (A, AAAA, PTR).
Closes#1219
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Co-authored-by: Azat Khuzhin <azat@libevent.org>
No evdns will do caching by default (with respect to TTL), to disable this set EVDNS_BASE_NO_CACHE
There are also helpers for manually manage the cache:
- evdns_cache_write()
- evdns_cache_lookup()
Initial PR: #571Fixes: #1715
Co-authored-by: Greg Hazel <ghazel@gmail.com>
Co-authored-by: Keith Moore <kmoore@clostra.com>
The base should be notified in case of timer removal if that was the
minimal timer in the base.
Reported-by: @moihn (who is also provided the reproducer on which this
test is based on)
Fixes: https://github.com/libevent/libevent/issues/1727
