c-ares / c-ares / 28594042315

90%

push

github

test: fix OpenBSD CI hang in MockTCPChannelTest.ReadFullFrameThenDisconnect (#1177)

## Problem

Every OpenBSD CI job hangs and is killed at GitHub's 6-hour ceiling. The
hang is deterministic and identical across every branch (including
`main`): `arestest` prints

```
[ RUN      ] AddressFamilies/MockTCPChannelTest.ReadFullFrameThenDisconnect/ipv4
```

and never returns. NetBSD, macOS and Linux all pass, so this is
OpenBSD-specific, not BSD-wide. (The `WARNING: clock gained 810 days` in
the OpenBSD logs is unrelated — it's just the VM image noticing the host
clock.)

## Root cause — a single-threaded test-harness deadlock, not a library
bug

The mock DNS server runs **synchronously in the same thread** as the
c-ares client: `ProcessWork` → `select()` → `ProcessFD` →
`ProcessRequest`. The client's `ares_process` only runs *after*
`ProcessFD` returns, so the client can drain a socket *between* the
server's sends, never *during* one.

`MakeMaxReadTcpAReply()` (added in #1138, and used by this one test
only) builds a reply whose TCP frame is exactly **65535 octets** to
exercise the `read_again` path. The mock server writes it with a
**single blocking `sendto()`** on a **blocking** `accept()`ed socket
that has no `SO_SNDBUF` tuning.

`send()` returns only once the data is copied into the kernel send
buffer, which requires `server_sndbuf + client_rcvbuf ≥ 65535`. c-ares
tunes neither buffer, so:

- **Linux / macOS / NetBSD** — large default loopback buffers hold the
whole frame → `send()` returns → test passes.
- **OpenBSD** — ~16k default buffers can't hold 65535 bytes → `send()`
blocks waiting for the client to drain — but the client can't run
because it's the same thread stuck in `send()`. **Permanent deadlock** →
6h timeout.

The `#1138` deferred disconnect-handling change that introduced this
test is correct; only the harness's assumption that a full-size reply
can be written in one blocking `send()` is wrong on small-socket-buffer
platforms.

## Fix

... (continued)

2 of 2 new or added lines in 1 file covered. (100.0%)

23751 of 25943 relevant lines covered (91.55%)

12315.6 hits per line