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
Previously it fails with, due to empty OPENSSL_FOUND:
CMake Error at /home/runner/work/libevent/libevent/build/LibeventConfig.cmake:64 (if):
if given arguments:
"3.30.3" "VERSION_LESS" "3.15.0" "AND" "1" "AND" "AND" "TRUE"
Unknown arguments specified
the following changes are introduced:
* openbsd CI fails with "too many open files", fixed with `ulimit -n` (now it fails for a more test-specific reasons)
* android CI fails with `pipe2` method not found, fixed by removing cache
* bumped freebsd to 13.4 (and 14.1) as they [reached EOL](https://www.freebsd.org/releases/)
* trying android-ci workflow
* focus on android
* fix workflow file
* another fix attempt
* update java
* added host targets
* added clause for skipping CI
* revert focus on android
* set push CI back to master branch
* fix CI cache key for android
