Fix up a couple of problems with configuring whether c-ares rotates
between different name servers between requests.
Firstly, ares_save_options() returns (in *optmask) the value of
(channel->optmask & ARES_OPT_ROTATE), which doesn't necessarily
indicate whether the channel is or is not actually doing rotation.
This can be confusing/incorrect if:
- the channel was originally configured without ARES_OPT_ROTATE
(so it appears that the channel is not rotating)
- the /etc/resolv.conf file includes the 'rotate' option
(so the channel is actually performing rotation).
Secondly, it is not possible to reliably configure a channel
to not-rotate; leaving off ARES_OPT_ROTATE is not enough, since
a 'rotate' option in /etc/resolv.conf will turn it on again.
Therefore:
- add an ARES_OPT_NOROTATE optmask value to allow explicit
configuration of no-rotate behaviour
- in ares_save_options(), report the value of channel->rotate
as exactly one of (optmask & ARES_OPT_ROTATE) or
(optmask & ARES_OPT_NOROTATE).
In terms of back-compatibility:
- existing apps that set ARES_OPT_ROTATE will continue to rotate,
and to have ARES_OPT_ROTATE reported back from ares_save_options()
- existing apps that don't set ARES_OPT_ROTATE will continue to
use local config/defaults to decide whether to rotate, and will
now get ARES_OPT_ROTATE or ARES_OPT_NOROTATE reported back from
ares_save_options() rather than 0.
Commit 46bb820be3 ("ares_init_options: don't lose init failure")
changed init behaviour so that earlier errors in initialization
weren't lost. In particular, if the user passes in specific
options but they are not applied (e.g. because of an allocation
failure), that failure needs to be reported back to the user; this
also applies when duplicating a channel with ares_dup().
However, other initialization failures can be ignored and
overridden -- in particular, if init_by_resolv_conf() or
init_by_environment() fail, then falling back to default values
is OK.
So only preserve failures from the init_by_options() stage, not
from all initialization stages.
Fixes issue 60.
GoogleTest assumes that there is a null pointer in argv[argc],
so make it look like that. Without this change, tests run with
command-line arguments get memory errors under valgrind/ASAN.
When fuzzing with AFL, if the LLVM-based instrumentation is
used (via the afl-clang-fast wrapper), then it is possible to
have a single execution of the fuzzer program iterate multiple
times over the fuzzing entrypoint (similar to libFuzzer's normal
mode of execution) with different data. This is much (e.g. 10x)
faster.
Add code to support this, by checking whether __AFL_LOOP is
defined at compile-time.
Also, shift the code to effectively be C rather than C++.
No need to depend on the rest of the test code (ares-test.h) for
the fuzzer entrypoint; this makes the entrypoint slightly simpler
to build with LLVM's libFuzzer.
Also shift the code to effectively be C rather than C++
The test binary built in the MinGW build is failing for some
reason. It works for me when I build locally, so I'm guessing
it's down to some sort of AppVeyor environment issue.
Disable for now.
Add a test script that runs the fuzzing command over the
corpus of DNS packets. This doesn't actually do any fuzzing
(it just runs them as inputs without generating any variations)
but it does ensure that the fuzzing entrypoint is still working.
For fuzz testing it is useful to start from a corpus of valid
packets, so fill out the test/fuzzinput/ directory with a bunch
of inputs.
These packets were generated by temporarily modifying the c-ares
process_answer() function to save off any incoming response messages.
On a build where MSAN has been manually set up (which involves
using an MSAN-instrumented version of the standard C++ library, see
https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo)
there's a warning about use of uninitialized memory here. It
might be a false positive, but the fix is trivial so include it.
The current approach for disabling tests is not a good solution because
it forces you to pass --disable-tests, rather than auto-detect if your
system can support the tests in the first place. Many (most?) systems
do not have C++11. This also causes issues when chain-building c-ares,
the hosting system needs to be updated to support passing this
additional flag if necessary, it doesn't seem reasonable to add this
requirement which breaks compatibility.
This change auto-detects if the system can build the tests and
automatically disable them if it cannot. If you pass --enable-tests to
configure and the system cannot build them either due to lack of system
support, or because cross-compilation is being used, it will throw an
appropriate error since the user indicated they really did want the
tests.
Daniel Stenberg
David Drysdale
Brad House
Chris Araman
svante karlsson
nordsturm
Chris Araman
Viktor Szakats