[ten9876]

Summary

Refs #6154, #6156. This doesn't close them: the sanitizer-slowdown timeouts are still open (see below).

The weekly Sanitizers lane recently started building the full test tree again (#6136, #6152). Its first complete run on main, 37208806037, failed 6 tests under ASan + UBSan and 11 under TSan. This PR fixes every one of those failures that was an actual sanitizer report. In the branch run 37230031178, neither lane reports a single sanitizer error. What still fails there is timeouts, plus one plain assertion in rtl_capture_worker_test (below).

Two of the eight commits change shipped DSP behaviour. They are vendored WDSP patches, documented in third_party/wdsp/AETHERSDR-PATCHES.md:

• Patch 16, transmit path. SetTXABandpassFreqs() was the only one of four TXASetupBPFilters() callers that didn't take csDSP. TXASetupBPFilters() clears bp1/bp2 run first and re-enables them only after the FIR redesign. So a TX filter change while transmitting with COMP (and CESSB) on could run blocks with the post-compressor bandpass bypassed, which is out-of-band splatter. Fix: take the lock, as SetTXAMode() does. It adds no new lock order, and costs one FIR redesign stall per TX filter change, which upstream already accepts for a mode change.

• Patch 17, panadapter analyzer.

  1. stop and end_dispatcher are now atomic.
  2. input_busy is released after stitch(), so the next frame's FFT workers can no longer overwrite results while the stitch is still copying them (a torn spectrum frame).
  3. sendbuf() now hands off IQout_index inside BufferControlSection, closing a lost update.

  Only part 2 changes timing: the next frame's FFTs start one stitch later, tens of microseconds.

Commit	Lane	Finding	Fix
1f9c4ed66	ASan	offline_health_registry_test: stack-use-after-scope. Section 6 reuses a factory that captured section 5's block-scoped RecorderState by reference	rec moves to main() scope (test only)
cacf9fe30 + 49fa9a75a	UBSan	rx_applet_squelch_reconciliation, vfo_dsp_launcher_width, fm_filter_controls: invalid QPointer<QLabel> downcast in VfoWidget::eventFilter during the collapsed label's teardown	Remove the filter before ~VfoWidget deletes the label, and test the event type before the guarded-pointer comparison. The second covers the label dying first, after beginDirectEntry() raise()s the VFO (found in review). Regression: gui_nested_lifetime_test vfoCollapsedLabelTeardownInEitherOrder, covering both child orders
01d06c6d1	TSan	receive_intent_routing, tci_automation, tci_server_review: lock-order inversion between two of Qt's own TLS-backend mutexes, both taken on the main thread	Anchored deadlock:QSslSocketPrivate::tlsBackendInUse suppression
f04a9ffb2	TSan	tci_server_review: unlocked global QStringList log sink written from worker threads	One mutex for the sink and its lists (test only)
6f6e4a5fd	TSan	tx_operation_integration: the command sink appends on the RadioConnection thread to a list destroyed before that thread is joined	Declare the list before radio (test only)
fbbd24087	TSan	wdsp_channel: WDSP patch 16 (above)	Lock in SetTXABandpassFreqs
af9c15224	TSan	anan_rxdsp_handedness, spectrum_sequence_gap, wdsp_process_tally: WDSP patch 17 (above)	Three analyzer hand-offs synchronised
31e249c3e	TSan	weather_radar_loading: Qt's QHttpThreadDelegate teardown vs a main-thread reply delete. Three map tests were fetching live OSM tiles	Stub network in those three tests, plus an anchored race:QHttpThreadDelegate::~QHttpThreadDelegate suppression

Each suppression in tests/sanitizers/tsan.supp carries its reasoning and a caveat. Neither is anchored on a frame AetherSDR code runs inside. The file's DO-NOT-ADD list is untouched. Note that a suppression hides every stack it matches, not only the reported cycle or teardown. So zero TSan reports with these entries means no unsuppressed race was seen. It is not proof that every Qt TLS or HTTP-teardown interaction is race-free.

Still failing after this PR, tracked in #6154 / #6156:

• Timeouts under the sanitizers' slowdown, with no sanitizer report. ASan: rtl_spectrum_averaging, weather_radar_loading. TSan: the same two plus audio_engine_rates, nr_stereo_independence, peripheral_auth_dialog.
• rtl_capture_worker_test, TSan lane only: fails the assertion "DC mode change discards old estimates and shows the actual first corrected window", with no race reported. This branch touches no RTL code, and the test passed in the same run's ASan lane. It passed in both lanes this morning, before main gained aetherd: consolidate slice receive-control routing #5919's RTL changes.

Leak fixes (added after the first push, found by a full local LeakSanitizer sweep):

Commit	Leak	Fix
6121f6ad6	RadioModel::disconnectClientHandlesThen: the step lambda captured its own shared_ptr, a cycle that leaked on every client-disconnect chain	Capture a weak_ptr; the in-flight sendCmd callback holds the strong reference
7577bab41 + 7f37cf045	WDSP patch 18: destroy_calcc() never closed the five PureSignal SemsPSCorr semaphores. 86 leak blocks across 17 tests (every TX channel destroy)	Close them, and the exit event, only once the correction thread has signalled exit; on the 500 ms timeout they are not freed under a live thread. This does not make the timeout path safe: destroy_calcc() still frees a, which a late thread would use. That hazard predates this PR and is now #6179
192e8f09a	phone_tx_filter_numeric_entry_test: sendEvent(…, new QFocusEvent) leaked, since sendEvent never takes ownership	Stack event (test only)

Why CI never reported these leaks: the ASan lane's ASAN_OPTIONS include halt_on_error=0, and with that, a leak doesn't change a test's exit code. The test "passes" and ctest --output-on-failure throws its output away. Verified with phone_tx_filter_numeric_entry_test: it exits 0 with CI's options and 1 with plain detect_leaks=1. Fixing that is a sanitizers.yml change and is not in this PR.

Full local sweep (all 653 tests, leaks counted as failures): 26 failed before these three commits. After them, the only leak left anywhere is whisper.cpp's ggml Vulkan backend registry, a process-lifetime static that only appears on a machine with a Vulkan GPU. Not ours, and CI has no GPU. The other non-leak failures are: the two known timeouts; connection_panel_size and local_control_server, which fail only on this machine with no sanitizer report and pass in CI; and rtl_receive_pipeline and cw_pcm_consumer, which fail intermittently (1 run in 3 serially, and under parallel load, respectively) with no sanitizer report. Those are flakes already on main, out of scope here.

Constitution principle honored

Principle VIII: every finding was reproduced before it was fixed. Each fix that could be checked locally was shown to fail without it and pass with it; the TSan-only fixes are proven by the branch dispatch. The two WDSP changes follow the vendoring rules: minimal, commented in place, and documented in AETHERSDR-PATCHES.md with what to keep on the next WDSP update.

Test plan

• Local build passes: full tree, Debug, with CI's ASan + UBSan flags and AETHER_SHARED_CORE=ON
• Red/green for both ASan fixes. Reverted, all 4 tests reproduce CI's exact reports (stack-use-after-scope at :95, downcast at qpointer.h:76). With the fixes they pass 3/3.
• 71 WDSP, ANAN, TX, HL2 DSP, map and edited tests under ASan + UBSan. All pass apart from the 2 known 30 s timeouts. weather_radar_loading_test run directly: 44 passed, 0 failed, 26 s.
• Red/green for the leak fixes. In a full-suite LSan sweep on the same tree, before vs after the three leak commits: 86 create_calcc blocks, 5 disconnectClientHandlesThen blocks and the QFocusEvent leak, down to none. All the affected tests pass with leak detection on, tx_operation_integration with 421/421 assertions. Leaks from this machine only (fontconfig/pango/GTK, NVIDIA cuInit, ggml Vulkan) were suppressed locally, not in the repo.
• Sanitizers workflow_dispatch 37230031178 tested 31e249c3e, the head before the leak fixes and the review fixes, not the final head. Zero sanitizer SUMMARY: reports in either lane, so every originally targeted test is green. The run still went red on the timeouts and on rtl_capture_worker_test. Its duplicate stickies ([sanitizer] ASan + UBSan weekly run failure (fp 033d48555465) #6165, [sanitizer] TSan weekly run failure (fp 1869b913d6f3) #6170) are closed into [sanitizer] ASan + UBSan weekly run failure (fp 55e8f7b54c82) #6154 / [sanitizer] TSan weekly run failure (fp 65304097123c) #6156.
• Sanitizers workflow_dispatch on the final head 7f37cf045, 37243767521: zero sanitizer SUMMARY: reports in either lane. ASan failed 2/656 and TSan 5/656, every one a known sanitizer-slowdown timeout. gui_nested_lifetime_test (the new VFO regression), phone_tx_filter_numeric_entry_test, wdsp_channel_test and rtl_capture_worker_test passed in both lanes.
• The same head plus ci(sanitizers): let a leak fail its test in the ASan lane. Principle VIII. #6176, so a leak fails its test, 37243769261, on the temporary branch ci/integration-6173-6176 (since deleted): no ASan, UBSan or LeakSanitizer report, and the same timeouts only. Its stickies [sanitizer] ASan + UBSan weekly run failure (fp 033d48555465) #6189 and [sanitizer] TSan weekly run failure (fp eaf76ff70558) #6191 are closed into [sanitizer] ASan + UBSan weekly run failure (fp 55e8f7b54c82) #6154 / [sanitizer] TSan weekly run failure (fp 65304097123c) #6156.
• VFO teardown red/green. The new vfoCollapsedLabelTeardownInEitherOrder aborts on the qpointer.h:76 downcast in its "label-dies-first" row with only the destructor fix. With the event-type-first check, all 10 cases pass, 3 of 3 runs. The 26 vfo/rx_applet/fm_filter/slice/lifetime tests pass.
• Behaviour on a real radio: patch 16 is a TX-path change. A COMP-on filter-width change while keyed should be checked on hardware and a dummy load before it ships.
• Existing tests pass (CI)

Checklist

• Commits are signed (docs/COMMIT-SIGNING.md)
• No new flat-key AppSettings calls
• Code is clean-room
• No meter UI touched
• Documentation updated: third_party/wdsp/AETHERSDR-PATCHES.md (patches 16, 17) and the in-file rationale in tests/sanitizers/tsan.supp. No CHANGELOG.md.
• Not security-sensitive

🤖 Generated with Claude Code

[github-actions]

Accessibility check findings

This PR touches src/gui/ files with 5 accessibility issue(s).
Full details appear as inline annotations on the diff above.

Files scanned : 1
Files with findings: 1
Total findings : 5

See docs/a11y.md for the canonical
Qt patterns (setAccessibleName, QAccessibleValueChangeEvent,
QAccessibleInterface subclasses, etc.). Structural remediation
(keyboard navigation, custom QAccessibleInterface subclasses)
is tracked in #3288.

Findings are warnings only — the build is not blocked.

[aethersdr-agent]

The two red checks are the sanitizer dispatch, not this PR's gate

Short version: nothing here looks like a defect you introduced, and the red X on 31e249c3e is the outcome your PR description already predicted.

The two failures on this SHA are TSan and ASan + UBSan from run 37230031178 — your own workflow_dispatch of sanitizers.yml, the run you cite as evidence. The per-PR gate is a different workflow; at the time of writing build, check-macos and check-windows are still in_progress, and Static checks, Sanitizer option configures and both CodeQL Analyze jobs are green. I won't predict the gate.

Why the lane went red with zero sanitizer reports

Both lanes got all the way through Configure → Build → Run tests under sanitizer. The only step that failed is the last one:

# .github/workflows/sanitizers.yml:425-427
- name: Fail the job if sanitizer reported errors
  if: steps.ctest.outputs.exit != '0'
  run: exit 1

Despite the step's name, the condition is ctest's exit code — any failing test turns the lane red, including a plain timeout with no sanitizer finding at all. So the residual timeouts you're tracking in #6154 / #6156 are sufficient on their own.

Your "zero reports" claim checks out

The stickies that run filed, #6165 (ASan, fp 033d48555465) and #6170 (TSan, fp 1869b913d6f3), both open their report block with --- last 50 KB of ctest output --- rather than a SUMMARY: line. That's the signature of a lane that produced no sanitizer report at all — the extractor had nothing to quote, so it fell back to the ctest tail. Independent of the PR description, those two issues confirm it. Both are already closed into #6154 / #6156, so there's nothing to do there.

What they actually record as failing:

Lane	Failed	Kind
ASan + UBSan	rtl_spectrum_averaging, weather_radar_loading	both Timeout
TSan	audio_engine_rates, nr_stereo_independence, rtl_spectrum_averaging, weather_radar_loading, peripheral_auth_dialog	Timeout
TSan	rtl_capture_worker_test	Failed

2 of 656 and 6 of 656 — and every one of those is either the sanitizer-slowdown timeout residue you scoped out, or the single rtl_capture_worker_test assertion you flagged yourself as TSan-lane-only with no race reported and possibly downstream of #5919's RTL changes. I haven't looked into that one, so I'll leave your read of it as the open item rather than second-guess it. Worth noting peripheral_auth_dialog_test passed under ASan at 23.03 s and timed out under TSan — consistent with slowdown against a tight per-test budget rather than anything in your diff.

One thing for the follow-up, not for this PR

The gate step's name promising "sanitizer reported errors" while its condition is a bare ctest exit code is exactly what made this SHA look like a regression when it isn't. If it's in scope for #6154 / #6156, distinguishing "reported a sanitizer error" from "a test failed" would stop future clean-lane runs from reading as red. Not something to fix here.

Thanks for doing this one properly — eight commits with per-commit red/green, two vendored WDSP patches documented in AETHERSDR-PATCHES.md, and suppressions that carry their own reasoning and aren't anchored on frames our code runs inside. Flagging the patch-16 TX-path change as still needing a dummy-load check on hardware is the right call to leave unticked rather than quietly assume.

🤖 Generated with Claude Code

---

_{🤖 aethersdr-agent · cost: $4.7195 · model: claude-opus-5}

[github-actions]

Accessibility check findings

This PR touches src/gui/ files with 5 accessibility issue(s).
Full details appear as inline annotations on the diff above.

Files scanned : 1
Files with findings: 1
Total findings : 5

See docs/a11y.md for the canonical
Qt patterns (setAccessibleName, QAccessibleValueChangeEvent,
QAccessibleInterface subclasses, etc.). Structural remediation
(keyboard navigation, custom QAccessibleInterface subclasses)
is tracked in #3288.

Findings are warnings only — the build is not blocked.

[ten9876]

Issue fit

Partially. Head 192e8f09abfb7269318c55b1d9d2deb3b91a85ca addresses the concrete reports in #6154/#6156 and explicitly leaves the sanitizer timeouts open. The VFO teardown change fixes one destruction order, but the same invalid downcast remains after normal direct-frequency entry changes sibling order. That needs completing before this sanitizer repair lands.

Scope

File/group	Change	Claimed?	Verdict
src/gui/VfoWidget.cpp	Detach collapsed-label event filter during VFO destruction	Yes	Relevant, incomplete lifetime repair
src/models/RadioModel.cpp	Break disconnect-chain shared-pointer cycle	Yes, later leak-fix section	In scope
tests/offline_health_registry_test.cpp	Extend captured recorder lifetime	Yes	In scope
tests/phone_tx_filter_numeric_entry_test.cpp	Stack-own synchronous focus event	Yes	In scope
tests/tci_server_review_test.cpp	Lock log sink and captured lists	Yes	In scope; socket-owning execution boundary below
tests/tx_operation_integration_test.cpp	Preserve captures until connection-thread join	Yes	In scope
tests/weather_radar_loading_test.cpp	Inject network manager for remaining map cases	Yes	In scope; removes unintended real HTTP
tests/sanitizers/tsan.supp	Two Qt-specific suppressions	Yes, caveats disclosed	In scope, narrower than generic Qt frames
third_party/wdsp/upstream/TXA.c	Lock TX bandpass reconfiguration	Yes	In scope
third_party/wdsp/upstream/analyzer.{c,h}	Atomic flags, stitch completion and ring-index synchronization	Yes	In scope
third_party/wdsp/upstream/calcc.c	Close correction-thread handles after successful exit signal	Yes, later leak-fix section	In scope
third_party/wdsp/AETHERSDR-PATCHES.md	Record vendored patches 16–18	Yes	In scope

The commit sequence corresponds to the documented initial fixes and later leak sweep. No new public command, dependency, settings/default, visual preference, or CHANGELOG change. These are defect repairs rather than an unapproved feature/design change. The checklists are broadly accurate apart from the evidence provenance qualification below.

Blocker

1. Complete the label teardown fix when the label dies before the VFO. src/gui/VfoWidget.cpp:764-771 only detaches the filter when ~VfoWidget() runs first. The collapsed label is a sibling owned by the VFO's parent, and beginDirectEntry() calls raise() at :5163, moving the VFO after that label in Qt's child order. Parent destruction then deletes the label while the VFO and its filter remain alive. eventFilter() at :6950 still evaluates the QPointer<QLabel> comparison before checking the event type, and teardown reaches the same invalid downcast this PR intends to fix.

A socket-free Qt 6.12 UBSan executable using the actual head VfoWidget.cpp reproduced:

normal parent teardown: exit 0
beginDirectEntry("review"); delete parent: exit 1
qpointer.h:76: runtime error: downcast ... does not point to an object of type 'QLabel'
object is of type 'QWidget'
VfoWidget::eventFilter ... VfoWidget.cpp:6950
QWidget::~QWidget -> QLabel::~QLabel -> QObjectPrivate::deleteChildren

This is an incomplete repair of the existing bug, not a newly introduced regression. Keep the destructor detach, and avoid reading the typed guarded pointer for teardown events. For this branch the minimal replacement is:

    if (event->type() == QEvent::MouseButtonPress && (obj == m_freqLabel || obj == m_collapsedFreqLabel)) {

Add a socket-free sanitizer regression that constructs a parent and VFO, enters direct entry, then destroys the parent, as well as the ordinary teardown order. With this one-line event-type-first change applied only to a scratch control, both teardown cases passed under UBSan.

Non-blocking nits / evidence boundaries

• PR body, Test plan; third_party/wdsp/upstream/calcc.c:1107: run 37230031178 tested 31e249c3e336c087d5a3f1056eff6ce1e942519a, not this head. “workflow_dispatch on this head” is inaccurate: the three later leak fixes depend on the separately described local sweep. Downloaded lane logs contain no actual sanitizer SUMMARY reports (occurrences are the report-extraction script itself), consistent with the narrower claim, but the overall run failed with the acknowledged other failures. Record the tested SHA and refresh the lane after remediation.
• third_party/wdsp/upstream/calcc.c:1100-1136, patch-18 documentation: leaving handles allocated on a 500 ms timeout avoids freeing those handles under a live waiter, but destroy_calcc() still frees a and its members afterward. A delayed correction worker can still use the freed object. This hazard predates this PR; qualify the timeout safety rationale and track it separately rather than presenting handle leakage as a complete safe-timeout policy.
• tests/sanitizers/tsan.supp:49-81: the added rules suppress every matching stack, not solely the reported main-thread Qt cycle/HTTP teardown. Their caveats correctly admit this limitation. I found no demonstrated newly hidden application race, but zero reports with these rules should not be described as proof that every underlying Qt interaction is race-free.

Verification and limits

• Compiled the actual changed VFO class under UBSan and exercised its real widgets/event filter. VfoWidget.h is identical between this head and dependency build 295bff6eb54609512b04ea1bd0244acd3cd45f22; that build's VFO implementation differs only by this PR's destructor hunk. The probe links that build's matching headers/dependency objects, replacing its VFO object and application main. This is focused actual-class evidence, not a full exact-head application build. No RadioModel, socket listener, real radio or transmitter was instantiated. The merge-base VFO source (verified byte-identical to 18c5245e5970f3ab2089df313f056a537995d7f9) fails both cases under the same probe; head fixes ordinary teardown only; the guarded head control passes both. All probe processes exited after testing.
• Extracted the exact base/head disconnectClientHandlesThen() implementations into a Qt ASan/LSan harness with injected command completion. Head preserved deduplication/ordering and released captures after success, command-never-reached rejection, callback discard, and owner destruction. Base leaked 1008 bytes in 26 allocations; head passed all four cases without that leak. This tests the production method with a transport double, not a live disconnect session.
• Independently audited WDSP lock order and publication. TX filter writes now share csDSP with the worker; application setters serialize through the existing setup mutex. Stitch finishes before the next frame can overwrite its data; input-index handoff shares the producer's buffer lock. LONG/Interlocked usage matches the Windows/POSIX portability layer. Successful PureSignal exit permits the new closes; the timeout limitation is called out above. I did not reproduce on-air splatter or measure the claimed tens-of-microseconds stitch cost.
• Base/head engine-boundary, command-plane, capability-record and touchpoint-manifest check logs are identical, with no new blocking finding or enforcement baseline change. The test recorder lifetime fix has the same socket-free ASan-failing/block-scoped versus passing/function-scoped mechanism reviewed in #6161. The focus event uses the correct synchronous ownership model.
• Preflight identified tci_server_review_test as opening a QWebSocketServer through TciServer on an ephemeral TCP port, plus local clients. The operator was notified; I did not build or execute that target. It is registered in default CTest when Qt WebSockets is present and runs in the full sanitizer workflow; the ordinary PR workflow’s filtered CTest steps do not run it. Its registration discloses the socket and cases fail fast on bind failure. It tests our own server rather than simulated radio firmware. The changed weather cases inject their network manager; no live HTTP was used for this review.

At final check, build, Windows, macOS and Static checks were successful on this head. Its earliest workflow creation was 2026-10-04T22:52:24Z, newer than current main 85f2a1249d655026adc017d00819c17b9b29ed3e (tip timestamp 2026-10-04T22:40:53Z), so no timestamp-based stale-merge gap was detected. Those ordinary checks are not the full sanitizer lane or whole-suite evidence.

No separate code-review skill was available; this was a manual audit with focused compiled probes. I did not drive a whole-app automation session: the lifetime failure was exercised directly in the production QWidget class under UBSan, and the TX behavior requires authorized hardware evidence beyond the simulator. No claim is made that the entire suite or radio-dependent behavior was independently verified.

Recommendation

Request changes. Finish the VFO lifetime repair and add the direct-entry teardown regression. Preserve the otherwise useful fixes, qualify the evidence and timeout claims, then rerun the sanitizer lane at the final head.

— Jeremy KK7GWY + Codex

[github-actions]

Accessibility check findings

This PR touches src/gui/ files with 5 accessibility issue(s).
Full details appear as inline annotations on the diff above.

Files scanned : 1
Files with findings: 1
Total findings : 5

See docs/a11y.md for the canonical
Qt patterns (setAccessibleName, QAccessibleValueChangeEvent,
QAccessibleInterface subclasses, etc.). Structural remediation
(keyboard navigation, custom QAccessibleInterface subclasses)
is tracked in #3288.

Findings are warnings only — the build is not blocked.

[ten9876]

Thanks. Every point is addressed on head 7f37cf045.

Blocker: VFO teardown when the label dies first. Reproduced, and fixed in 49fa9a75a.

• eventFilter now checks event->type() == QEvent::MouseButtonPress before comparing against m_freqLabel / m_collapsedFreqLabel, as you suggested, so the guarded QPointer<QLabel> is never read for a teardown event. The destructor's removeEventFilter() stays, for the VFO-first order.
• Regression test: gui_nested_lifetime_test gets vfoCollapsedLabelTeardownInEitherOrder. It is socket-free and data-driven over vfo-dies-first and label-dies-first. The second row calls beginDirectEntry() and then deletes the parent. Each row asserts the parent's child order it claims, so it really exercises that path.
• Red/green under CI's ASan + UBSan flags: with only the destructor fix, label-dies-first aborts on the qpointer.h:76 downcast. With the event-type-first check, all 10 cases pass, 3 of 3 runs. The 26 vfo/rx_applet/fm_filter/slice/lifetime tests pass.

Evidence SHA. Corrected in the PR body. Run 37230031178 tested 31e249c3e, before the leak fixes and the review fixes, and the body now says so, and that the run was still red on the timeouts and rtl_capture_worker_test. A fresh lane run on the final head is in progress: 37243767521 on 7f37cf045.

calcc timeout. Agreed: leaving the handles allocated isn't a safe timeout policy, because destroy_calcc() still frees a. 7f37cf045 corrects both the in-code comment and patch 18's documentation to say so: patch 18 only stops the successful-exit path leaking, and adds no second hazard on the timeout path. The pre-existing use-after-free is tracked as #6179, which lists two possible directions and decides neither.

tsan.supp scope. Agreed, and the PR body now says it plainly. Each entry hides every stack it matches. Zero reports means no unsuppressed race was seen, not that the Qt TLS or HTTP-teardown interactions are race-free. The caveats in the file already say this.

tci_server_review_test sockets. Noted. The only change to it is the log-sink mutex; its ephemeral-port QWebSocketServer behaviour is unchanged.

[ten9876]

Issue fit: Refs #6154 and #6156; it closes neither, by design. Its intent is to clear every real sanitizer report from the full-tree lane's first complete run. At head 7f37cf04 that holds as far as I could verify it:

• The 23:15Z review's blocker (the VFO teardown when the label dies first) is fixed, and the new test pins it. I mutation-checked it (below).
• Every ASan, UBSan and leak fix I reverted is caught.
• The final-head lane run 37243767521 was still in progress when I posted. The earlier 37230031178 (on 31e249c3e) has 0 SUMMARY: lines in its full log; its failures are exactly the five timeouts plus rtl_capture_worker_test, as the body now says.

No blockers, so I'm posting this as COMMENT.

Scope

Commit	Files	Claimed?	Verdict
1f9c4ed6	tests/offline_health_registry_test.cpp	Yes	In scope. Same fix as #6161, see nit 1
cacf9fe3, 49fa9a75	src/gui/VfoWidget.cpp:764-770, 6950-6956, tests/gui_nested_lifetime_test.cpp:81-122	Yes	In scope; nit 3
01d06c6d, 31e249c3	tests/sanitizers/tsan.supp, tests/weather_radar_loading_test.cpp	Yes	In scope; nit 4
f04a9ffb, 6f6e4a5f	tests/tci_server_review_test.cpp, tests/tx_operation_integration_test.cpp	Yes	In scope; test-only
fbbd2408	third_party/wdsp/upstream/TXA.c (patch 16)	Yes	In scope; shipped TX-path change, nit 5
af9c1522	analyzer.c, analyzer.h (patch 17)	Yes	In scope; shipped DSP timing change, disclosed
6121f6ad	src/models/RadioModel.cpp:7101-7135	Yes	In scope
7577bab4, 7f37cf04	third_party/wdsp/upstream/calcc.c:1101-1115 (patch 18), plus its timeout caveat (#6179)	Yes	In scope
192e8f09	tests/phone_tx_filter_numeric_entry_test.cpp	Yes	In scope
—	third_party/wdsp/AETHERSDR-PATCHES.md	Yes	In scope; nit 2

• All 13 commits were authored 2026-10-04, and each maps to the body.
• No CHANGELOG entry, settings, capabilities or public surface.
• tsan.supp's DO-NOT-ADD list is untouched. Both new entries follow the file's own rule ("a stack, an issue, and a narrow anchored entry with a caveat", tsan.supp:17-19).

Socket preflight.

• tests/tci_server_review_test.cpp is a modified socket-owning test: TciServer plus QWebSocket, our own server surface, at tests/tests.cmake:5447-5453 with its fail-fast note. Per docs/agents/tests-ci.md I did not build or run it. The change is a test-only mutex around the log sink, and I reviewed it by reading.
• gui_nested_lifetime_test (new case) and tx_operation_integration_test are socket-free, so I ran them.

Blockers

None.

Nits (non-blocking)

1. tests/offline_health_registry_test.cpp:196-202 duplicates #6161. #6161 (on8st, opened 19:39Z) makes the identical move of RecorderState rec to main() scope, on the same lines, so whichever lands second conflicts. I checked both placements: every RadioModel in that file is block-scoped, so they are equivalent. One of the two should drop the hunk.

2. third_party/wdsp/AETHERSDR-PATCHES.md: patch-number collision. Open #5974 (RTL WFM) also adds "Patch 17" and "Patch 18", with matching in-source AetherSDR patch N comments. Whichever lands second must renumber both the doc and the C comments (analyzer.c:656,909,1078, calcc.c:1101 here).

3. VfoWidget.cpp:764-770: the destructor's removeEventFilter() is now redundant, which contradicts the 23:27Z reply ("stays, for the VFO-first order"). I reverted only that hunk at 7f37cf04, keeping the event-type-first check, and rebuilt under CI's ASan+UBSan flags:

   • gui_nested_lifetime_test passes both vfo-dies-first and label-dies-first, with 0 SUMMARY: lines.
   • rx_applet_squelch_reconciliation_test, which tripped the original report, also passes cleanly.

   Every teardown event is a non-MouseButtonPress, so the reordered condition never reaches the QPointer<QLabel> comparison in either order. Either drop the block and its comment, or reword the comment to call it defence-in-depth. As written, it claims a necessity nothing exercises.

4. tests/sanitizers/tsan.supp: the race:QHttpThreadDelegate::~QHttpThreadDelegate entry has no demonstrated remaining trigger.

   • 31e249c3 makes the three offending map tests hermetic (ControlledRadarNetwork). After that, no test in the TSan graph is shown to delete a real QNetworkReply on the main thread.
   • The dispatch ran with both changes together, so it can't show whether the stub alone was enough.
   • A suppression with no live trigger only blinds (its own caveat: "hides any race whose stack contains ~QHttpThreadDelegate").
   • Either drop it and let the final-head run decide, or name the test that still reaches it.

5. third_party/wdsp/upstream/TXA.c:789-798 (patch 16) is a shipped TX-path change, and its hardware check is still unchecked in the body.

   • The lock order is not new: WdspChannel::setMode() already calls SetTXAMode() (which takes csDSP) under the same g_setupMutex (WdspChannel.cpp:548 vs :572).
   • csDSP is recursive in the port (wdsp_port.c:100).
   • The new cost is one FIR-redesign stall of the DSP thread per keyed TX filter change. Whether the dummy-load check gates the merge is the operator's call.

6. History in comments (AGENTS.md §"Comments"). Each of these narrates the finding; the commit messages already carry it.

   • gui_nested_lifetime_test.cpp:81-91 (11 lines, "was an invalid downcast (UBSan, #6154)").
   • offline_health_registry_test.cpp:197-200 ("Block-scoped, that was a stack-use-after-scope").
   • RadioModel.cpp:7101-7105 ("a strong one made the function own itself … every call leaked it").

What I verified, and what I tried to break

Build. I built the PR head with CI's exact ASan lane flags: CFLAGS/CXXFLAGS=-fsanitize=address,undefined -fno-sanitize-recover=undefined -fno-omit-frame-pointer, Debug, AETHER_SHARED_CORE=ON. Under #6176's leak-failing options, these 10 targets exit 0 with no SUMMARY: line:

• At 192e8f09: offline_health_registry, phone_tx_filter_numeric_entry, rx_applet_squelch_reconciliation, fm_filter_controls, tx_operation_integration, wdsp_channel, anan_rxdsp_handedness, spectrum_sequence_gap and wdsp_process_tally.
• At 7f37cf04: gui_nested_lifetime_test (10/10), plus a re-run of the VFO/rx_applet/fm_filter tests.

Mutations. I reverted each fix and rebuilt. Every one is caught:

Reverted	Test	Result
1f9c4ed6 rec scope	offline_health_registry_test	stack-use-after-scope, exit 1
49fa9a75 event-type-first only	gui_nested_lifetime_test	vfo-dies-first PASS, then label-dies-first aborts: qpointer.h:76: runtime error: downcast … not … 'QLabel'
49fa9a75 + cacf9fe3	gui_nested_lifetime_test	vfo-dies-first aborts on the same downcast
6121f6ad weak self	tx_operation_integration_test	216 byte(s) leaked in 5 allocation(s)
patch 18	wdsp_channel_test	leaks from create_calcc → CreateSemaphoreW (calcc.c:1079)
192e8f09	phone_tx_filter_numeric_entry_test	24 byte(s) leaked

The new lifetime test does what its body claims: each row pins its own destruction order. It only fails under UBSan, though, so its coverage lives in the weekly sanitizer lane, not in per-PR CI. The three leak mutations exit 0 under the lane's current options and exit 1 only with #6176's, which supports landing #6176 right after this.

I restored by git checkout, touched the files and compared sha256 against HEAD before every clean re-run.

Logic I walked.

• disconnectClientHandlesThen. The local step stays strong through the first call. Each in-flight sendCmd callback holds self. On commandNeverReachedRadio the callback drops and the chain frees without completion, which is the old behaviour minus the leak.
• Patch 17. InterlockedAnd/InterlockedExchange on the new volatile LONG (int32_t, wdsp_port.h:26) are real atomics. InterlockedDecrement(pnum_threads) stays last, so SetAnalyzer's drain is unchanged.
• Patch 18. The other ReleaseSemaphore(SemsPSCorr[…]) callers (calcc.c:1929,2023,2100,2113) are pscc() and API setters, not a second thread. The new caveat and #6179 correctly own the timeout-path UAF that patch 18 doesn't fix.

Not run.

• TSan locally. Arch's TSan runtime dies on any second QThread.
• tci_server_review_test, per the socket preflight.

One unattributed observation. In a mutated tree, wdsp_channel_test once failed sweep DIGU at 150 Hz was fault-free while six other builds were running. Three clean runs on the restored head passed. I'm reporting it as load-sensitivity, not as this PR's.

CI. Runs on 7f37cf04 were created 23:26Z, after main's 22:40Z tip, so they are current. The Sanitizers dispatch on this head was still in progress.

Recommendation: Approve with nits once 37243767521 completes without a sanitizer report. Next steps:

• Settle the #6161 overlap and the #5974 patch numbering.
• Decide on the delegate suppression and on the patch-16 hardware check.

— Jeremy KK7GWY + Claude

[ten9876]

Maintainer ruling: #6173 lands the offline_health_registry_test fix; #6161 is closed in its favour. Keep commit 1f9c4ed6.

— Jeremy KK7GWY + Claude

[ten9876]

Lane rerun on the final head 7f37cf045: 37243767521 has zero sanitizer reports in either lane. The only failures are the known timeouts: ASan 2/656, TSan 5/656. The new vfoCollapsedLabelTeardownInEitherOrder regression and rtl_capture_worker_test passed in both lanes. The same head plus #6176, with leaks failing tests, 37243769261, also has no leak or other sanitizer report. The PR body's test plan is updated.