Most of the time we only need a read _or_ a write callback registered
with libuv - for example, on a UDP request a write callback is
registered, when executed the write callback performs the write,
deregisters itself, and registers a read callback.
However there is one case where getdns registers both read and write
callbacks: when a backlog of TCP requests is going to the same upstream
resolver, we use a single fd and queue the requests. In this instance we
want to listen for both read (to get responses for requests we've
already sent) and write (to continue to send our pending requests).
libuv, like most event libraries, only allows one callback to be
registered per fd. To get notification for both reads and writes, you
should examine the event flags and have appropriate conditional logic
within the single callback. Today getdns incorrectly tries to register
two separate poll_t with libuv, one for read and one for write - this
results in a crash (internal libuv assertion guaranteeing that only a
single poll_t is registered per fd).
Testing was done by using flamethrower
(https://github.com/DNS-OARC/flamethrower) to toss queries at a program
that embeds getdns.
Note that a higher qps trigger a _different_ getdns/libuv crashing bug
that occurs when the TCP backlog grows so large that requests start to
time out. That crash is not addressed in this PR, and will be more
involved to fix.
for the query, just like connection setup timeout was, so fallback transport have a chance too when TCP connection setup is less well detectable (as with TCP_FASTOPEN on MacOS).
Now GnuTLS 3.6.5 and later are in the field, we've run into problems handshaking with TLS1.3 servers with a GnuTLS build. OpenSSL works fine. Comparing the client handshake of GnuTLS and OpenSSL, we found GnuTLS was being considerably more restrictive. This change loosens the restriction so GnuTLS presents nearly the same set of cipher and other options and OpenSSL. OpenSSL provides more signature algorithms. The change gets GetDNS working against Quad1, Quad8, Quad9 and the getdnsapi servers.
1. ub_ctx_set_stub is in unbound.h, not unbound-events.h.
2. Only bother looking for unbound event API if enabled.
3. If building stub only, ensure all libunbound items are off. This is necessary in case we first configure without stub only, and then change to stub only.
Fixes#463
On the first call to tls_create_object (stub.c), tls_fallback_ok is read
before being initialized. This patch initializes tls_fallback_ok to 0 in
upsteam_init (context.c)
Valgrind complains about the uninitialized value:
==14774== Conditional jump or move depends on uninitialised value(s)
==14774== at 0x1528C3: tls_create_object (stub.c:900)
==14774== by 0x1556AD: upstream_connect (stub.c:2065)
==14774== by 0x15582E: upstream_find_for_transport (stub.c:2109)
==14774== by 0x1558B7: upstream_find_for_netreq (stub.c:2130)
==14774== by 0x156027: _getdns_submit_stub_request (stub.c:2296)
==14774== by 0x1421C8: _getdns_submit_netreq (general.c:478)
==14774== by 0x14261D: getdns_general_ns (general.c:636)
==14774== by 0x142905: _getdns_general_loop (general.c:731)
==14774== by 0x1432FB: getdns_general (general.c:888)
==14774== by 0x118B94: incoming_request_handler (stubby.c:692)
==14774== by 0x14F46B: udp_read_cb (server.c:762)
==14774== by 0x15C86B: poll_read_cb (poll_eventloop.c:295)
==14774== Uninitialised value was created by a heap allocation
==14774== at 0x483877F: malloc (vg_replace_malloc.c:309)
==14774== by 0x123CCF: upstreams_create (context.c:581)
==14774== by 0x128B24: getdns_context_set_upstream_recursive_servers (context.c:2760)
==14774== by 0x12DBFE: _getdns_context_config_setting (context.c:4646)
==14774== by 0x12FF47: getdns_context_config (context.c:4769)
==14774== by 0x1178C2: parse_config (stubby.c:297)
==14774== by 0x117B24: parse_config_file (stubby.c:343)
==14774== by 0x11919F: main (stubby.c:833)