[ten9876]

Refs #6096

What was wrong

Hl2Backend forwards three signals from each receiver's DSP to the seam under that receiver's UI number: spectrumReady → spectrumFrameReady, audioReady → slice audio, and meterUpdate → the slice S-meter. Only the audio forward checked which DSP sent the signal. The spectrum and meter forwards checked only m_ids.byUi(ui), which tells you the UI number exists but not who produced the value.

The DSP emits on the I/O thread and the forwards run on the backend's thread, so every frame and meter sample is a queued call. Closing a receiver calls disconnect(this) and deleteLater() on its DSP. Neither cancels a call that is already queued. createPanadapter() gives out the lowest free UI number, so a receiver reopened before delivery gets the closed one's number. The closed DSP's output then passed the byUi check:

• spectrum: its frame was published as the new receiver's spectrum. fix(rtl): gate worker spectrum and read errors after disconnect. Principle VIII. #6107 noted this gap in a comment and left it open.
• meter: its sample went into the new receiver's SMeterSmoother. A fresh smoother publishes its first reading immediately, so the stale value showed on the new receiver's S-meter. It also started the smoother's 100 ms throttle and became part of the smoothed value, so the receiver's own first reading was held back and blended with it.

Rule 6 is not involved: the DSP emits on the thread that emits linkDown, so nothing is delivered after disconnected(). That ordering argument is unchanged and the comment still states it.

Fix

src/core/backends/hl2/Hl2Backend.cpp: the spectrum and meter forwards now capture producer = QPointer<Hl2RxDsp>(dsp) and use the same guard as audioReady:
if (!producer || !receiver || receiver->dsp != producer.data()) return;
The comment at the spectrum forward states the rule for all three forwards: a value is published only while its producer is still the DSP behind its UI number.

Validation

• hl2_pan_create_async_test (socket-free; it already closes and reopens UI 1 without a radio) gets a new section that runs twice. It attaches SeamThreadAffinityProbe to every seam signal, then:

  1. Positive control: one spectrum frame and one meter sample from UI 1's DSP both publish, so the test can fail.
  2. Queues a frame and a meter sample from that DSP, closes UI 1, reopens it, checks it got UI 1 back, then delivers the queued calls. Neither may publish.
  3. The reopened receiver's own frame publishes, and so does its own meter sample, at exactly its own value. That shows the stale sample neither started the smoother's throttle nor was blended in.
  4. Every seam signal was emitted on the backend's thread.
  • In run 1 the closed DSP is already deleted when the queued calls arrive. In run 2 a test event filter drops its DeferredDelete, so it is still alive. Run 2 tests the dsp != producer term: in run 1 the QPointer alone would catch the stale values.

• Red before the fix: on unfixed main the stale frame was published.

• Mutation checks, one forward at a time (each restored, sha256 compared to the fixed file, rebuilt green):

  Forward	Mutation	Result
  spectrum	guard → !ids (old code)	fails both runs
  spectrum	identity term dropped	fails run 2
  meter	guard → !r (old code)	fails both runs (stale sample published; reuser's own reading throttled/blended)
  meter	identity term dropped	fails run 2
  either	!producer dropped	passes, as expected: when the receiver has a DSP, a null producer already fails the identity test. The term is kept so all three forwards have the same shape.

• hl2_pan_create_async_test 138/138 checks, stable over 5 runs. backend_seam_affinity_test passes. CTest: 2/2 selected, 2/2 passed. No socket-binding HL2 test was run.

• Static gates, merge base c7513e12 vs head, identical results on both: check_engine_boundary --strict (102 findings, 0 new), gen_touchpoint_manifest --check, check_capability_records --strict (71 at the frozen 71), check_command_plane --strict (401 = baseline), gen_seam_probe_table --check.

• No proof through the agent automation bridge. The demo sim cannot build an HL2 backend, so the unit test is the proof. This was not tested on HL2 hardware.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AADGw3HVn5FMMVrx2RQZ9g

[aethersdr-agent]

1. Issue fit

Partially — and the body is honest about which part. #6096 asks for two things: a structural publishSpectrumFrame() choke point on IRadioBackend mirroring publishLegacyAudio(), and verification of the RtlSdr and HL2 spectrum forwards as live Rule-6 holes. This PR does neither. What it fixes is the adjacent defect that #6107's comment explicitly flagged and left open — a queued frame/meter sample from a retired DSP publishing under a recycled UI number — and the body says "Refs #6096", not "fixes", and states plainly that "Rule 6 is not involved." That framing survives scrutiny: the DSP emits on the thread that emits linkDown, so connectedness genuinely is not the failure mode here; UI-number recycling is. #6096 stays open with the base-class gate and the RtlSdr survey unaddressed (the RTL side landed separately in c7513e1).

The recycle bug has no issue of its own, but GOVERNANCE.md does not require one for a bug fix with a stated root cause, and the root cause here is stated precisely.

2. Scope

File / group	What it changes	Claimed?	Verdict
src/core/backends/hl2/Hl2Backend.cpp	spectrumReady and meterUpdate forwards capture producer = QPointer<Hl2RxDsp>(dsp) and gain the producer-identity guard audioReady already had; the block comment is rewritten to state the rule for all three	Yes	In scope
tests/hl2_pan_create_async_test.cpp	New aStaleSpectrumFrameDoesNotPublishOnTheReuser(bool) section run twice, plus Access::sliceMeterName, a KeepAlive event filter, and four includes	Yes	In scope

Everything in the diff is explained by the stated fix. Two files, two commits, one per forward. No CHANGELOG entry, no build-config churn, no UI or default changed — nothing for §6 to classify.

The one - line worth calling out, since §3 asks for it: the diff deletes a comment that names a symptom —

"Unlike audioReady below, there is no producer check: a frame queued by a closed receiver's DSP publishes if its UI number was reopened before delivery."

That removal is correct. The comment described the defect, the defect is now fixed, and the new test pins it. Not a regression.

Completeness. grep -n "connect(dsp, &Hl2RxDsp::" on the head checkout returns exactly three sites (Hl2Backend.cpp:843, :865, :887) and Hl2RxDsp.h:508-511 declares exactly three signals. All three now carry the identical guard. No sibling forward left behind.

Socket audit. No socket test added or modified. bringUp() asserts Access::transportIdle(backend), the new section drives createPanadapter/removePanadapter directly, and tests.cmake:1460-1463 links only Qt6::Core Qt6::Network Qt6::Test against an already-registered target that joins AETHER_SETTINGS_CONSUMERS (tests.cmake:7202) and isolates via TestSettingsProfile. Nothing to flag.

3. Blockers

None.

4. Nits (non-blocking)

• The !producer term is load-bearing in a way the body undersells. The mutation table says dropping it "passes, as expected… when the receiver has a DSP, a null producer already fails the identity test. The term is kept so all three forwards have the same shape." It does more than that: it closes ABA. If the retired Hl2RxDsp is destroyed and a replacement lands at the same address and is stored as receiver->dsp, the raw pointer compare passes wrongly and only the cleared QPointer rejects. A mutation test can't reach that state deterministically, which is exactly why the term deserves a better justification than "same shape." (There is also the receiver->dsp == nullptr + concurrently-cleared-producer case, but I traced removePanadapter, buildReceivers and the mid-build failure path at Hl2Backend.cpp:2596 and found no event-loop spin between dsp = nullptr and reassignment, so I don't believe that one is reachable.) Inline comment on the spectrum guard.
• hl2_pan_create_async_test does not gate a merge. grep -n ctest .github/workflows/ci.yml shows the only -R filters are the digital-voice set, cross_needle_meter_test, mac_nr_filter_test and asr_gpu_probe_test. This target compiles in the Linux build job and is never executed in CI. The body's "CTest: 2/2 selected, 2/2 passed" is a local run, which is fine and disclosed — just don't read the green badge as evidence the new section passed. Nothing for the author to change; noting it so the maintainer weights the evidence correctly.

5. What I tried to break

• Does the bug exist at all, i.e. does disconnect(this) + deleteLater() cancel an already-posted call? removePanadapter (Hl2Backend.cpp:1283-1289) does both, but Qt's QMetaCallEvent::placeMetaCall invokes the stored slot object with no connection-liveness re-check, and the receiver (this, the backend) is still alive so nothing calls removePostedEvents. The premise holds. Reasoned from Qt semantics, not observed — I have no build or test run.
• Would the test pass against unfixed main? No. The old guard is if (!m_ids.byUi(ui)) return;, and after removePanadapter(1) + createPanadapter() byUi(1) resolves to the reuser, so the stale frame publishes → framesOnUi1 == 2 → the check fails. Run 2 (KeepAlive swallowing DeferredDelete) is the one that actually exercises receiver->dsp != producer.data() rather than the QPointer, and the filter is correctly moveToThread'd onto the chain's thread before installEventFilter. The test is not asserting the implementation back to itself.
• Is the meter assertion's exactness real or decorative? Real. WdspSMeter.h:119-142: a reset() smoother has !m_have, so feedAt stores the raw value and publishes immediately. Had the stale sample reached it, m_have would be true, the next value would be blended at kAttackAlpha/kDecayAlpha and throttled for 100 ms, so < 1e-6 against oldDbm + (kReuserDbfs - kOldDbfs) would fail. The reuser's Receiver seed; in createPanadapter is default-constructed, so its smoother is genuinely fresh.
• Does the stricter guard drop a legitimate frame? I walked DDC renumbering: m_rx.erase + m_ids.remove shift indices while leaving UI numbers alone, and the lambda captures ui (not ddc), so a survivor's queued frame still resolves through byUi → rx(ddcIndex) → the same dsp. createPanadapter sets r->dsp synchronously via openReceiverDsp before the async WDSP build, so the reuser is never transiently dsp == nullptr in a way that would also reject its own frames.
• Is the cross-thread QPointer read a race? The lambda runs on the backend thread while the chain is destroyed on m_ioThread. The null check reads an atomically-refcounted weak-pointer field, and producer.data() is only compared, never dereferenced, so there is no UAF even on an unlucky interleaving — and worst case it fails closed (drops a frame). This is also byte-for-byte the guard audioReady has carried on main, so the PR introduces no new pattern.
• Collateral on existing tests. hl2_backend_seam_test.cpp:412's meterUpdate spy drives the TX telemetry path (forwardPowerWindowPeakWhileKeyed), not a receiver DSP; the other spectrumReady/meterUpdate connects in hl2_rxdsp_test, hl2_pan_averaging_test, hl2_adc_sampling_seam_test and spectrum_sequence_gap_test attach to standalone Hl2RxDsp objects with no backend in the loop. Unaffected.
• Could not check: I could not reproduce the mutation table, the "138/138 checks, stable over 5 runs", or the static-gate counts. All findings and clearances above are reasoned from the head checkout at /tmp/aetherclaude/pr-6113, not from a build or a radio.

6. Recommendation

Approve with nits. The defect is real and precisely diagnosed, the fix is the pattern audioReady already established rather than a new invention, all three forwards are now identical so there is no sibling left broken, and the test fails against the unfixed guard in both runs — including the ABA-adjacent path that only run 2 reaches. The PR body is unusually honest: it marks the one uncovered guard term, says plainly there is no hardware or bridge proof, and does not claim to close #6096. My only substantive ask is a comment tweak explaining that !producer closes ABA rather than merely matching shape; the CI-gating note needs no action. Next step: a maintainer confirms #6096 stays open for the publishSpectrumFrame() choke point, and merges this on the unit test as the stated proof.

Thanks for the mutation table — it made the test's claims checkable without a build, which is exactly what a headless reviewer needs.

---

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

[ten9876]

Admin-merged on the maintainer's approval (self-authored PR, so a GitHub approval isn't possible). Head 55b777159:

• 1 of 1 review threads answered with evidence and resolved.
• On the merged tree, 63 of 64 socket-free hl2_* tests pass. The one failure is the four known hl2_backend_seam_test checks from feat(tx): apply TUNE power live while TUNE is keyed (HL2, Icom). Principle VI. #6104 ([full-suite] test suite failing on main (fp 32fb57419e1f) #6122, fix-forward in progress), so this PR adds no new failures.
• Required checks green. Drift since the run: fix(ci): deploy Qt 6.12's single Wayland platform plugin in the AppImage. Principle VIII. #6112 only, which is workflow-only, touches none of this PR's files and merges cleanly.

Main's Full Suite on this squash commit is expected to show those four known failures until the #6122 fix lands.

[on8st]

The new section of hl2_pan_create_async_test fails on macOS, every time: 60 of 60 runs on clean main d2e85fa3 (Apple silicon, Qt 6.12.0), idle and under load.

[FAIL] the reuser has its own chain

Cause: tests/hl2_pan_create_async_test.cpp:766 compares newDsp != oldDsp by raw address. In the "deleted" run the I/O thread has already freed the old chain when createPanadapter() allocates the new one, and macOS returns the same block. A diagnostic print showed old == new in 30 of 30 runs; in the "still alive" run they differ.

The guard itself is fine: the stale frame and meter checks pass in all 60. Comparing against the QPointer (oldGuard) would hold on both platforms.

Not checked: Linux (CI's Full Suite is green), Windows, any commit after d2e85fa3.

73, ON8ST