You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Round-2 review of the resolve-coalesce fix surfaced two latent bugs the
TSAN job and existing tests don't directly exercise:
1. gResolveDeferredTeardownDelay is read on the Matter event-loop thread
(ScheduleDeferredTeardownForResolves) and written from gtest fixture
threads (Set/TearDown via SetResolveDeferredTeardownDelay). TSAN
correctly flags this as a data race. Switch the storage to
std::atomic<uint32_t> with relaxed ordering -- value freshness is fine,
we just need the read/write itself to be torn-free and synchronized.
2. The Resolve() rescue paths cancel the deferred-teardown timer on every
eligible sibling ResolveContext for an instance name but only promote
the FIRST as primaryCtx. The remaining siblings stayed alive in
MdnsContexts with their own DNSServiceRefs and (after the rebind)
would each receive and dispatch the same logical resolve result --
producing duplicate callback invocations and DNSServiceRef leaks until
the next ChipDnssdResolveNoLongerNeeded swept them up. Collect non-
primary siblings during the scan and Finalize(CHIP_ERROR_CANCELLED)
them after the rebind+counter-bump commits, restoring the single-
canonical-context invariant the rest of the rescue path relies on.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
0 commit comments