c-ares / c-ares / 28722020255

90%

push

github

Fix UDP socket exhaustion regression: retire connections per-connection, not via server failure count (#1197)

Fixes #1152 — the v1.34.6 UDP-socket-exhaustion regression.

## Root cause

`ares_fetch_connection()` refused to reuse a UDP connection whenever the
**server's** `consec_failures > 0`, and `ares_check_cleanup_conns()`
keyed cleanup on the same server counter. But `consec_failures` is a
**server-health** metric:

- it's set by a single transient failure (one dropped packet → one
timeout) and only clears on a *successful* reply, and
- a server legitimately has **multiple** live connections (via
`udp_max_queries` cycling — and, ironically, because this guard itself
opens new connections while leaving the old one to drain).

So one connection's blip poisoned reuse of **every** connection to that
server. Worse, after opening a replacement, the very next query
re-checked the still-nonzero server counter and opened *another* — a new
UDP socket per query until the next success. The reporter measured
**1,651 sockets vs 13**, exhausting ephemeral ports / fds.

Introduced in **1.34.6** via #1032 (main) → backported by #1033. Present
identically on `main` and `v1.34`.

## Fix

Track eligibility **on the connection**, not the server:

- New `ARES_CONN_FLAG_NONEW`. When a query times out on a connection,
mark *that* connection so it takes no new queries — its in-flight
queries keep draining and it's cleaned up once idle (unchanged
behavior), and new queries go to a single fresh connection that is then
reused.
- Both connection-decision guards (`ares_fetch_connection` reuse +
`ares_check_cleanup_conns` cleanup) now test the per-connection flag.
- `server->consec_failures` stays purely a server-health/selection
signal.

This preserves the #1000 fix (a bad connection is still not handed new
queries) without evicting healthy connections. It also fixes a latent
wart: a *healthy* idle connection was previously force-closed just
because its server had an unrelate... (continued)

29 of 30 new or added lines in 3 files covered. (96.67%)

24039 of 26752 relevant lines covered (89.86%)

15990.1 hits per line