AetherSDRCrashReport.log
What happened?
Clicking the +TNF button (Add Tracking Notch Filter) in the spectrum overlay or toolbar causes AetherSDR to crash immediately. The crash is reproducible and occurs at the point of TNF creation — either before or immediately after the tnf add command is sent to the radio. No TNF notch appears on the panadapter, and the application terminates without a visible error dialog.
What did you expect?
Clicking +TNF should send a tnf add freq=<center_frequency> command to the FLEX-6600 over the TCP command channel (port 4992), receive a response with the new TNF's ID, and render a draggable notch filter overlay on the panadapter spectrum at the current center frequency. The TNF should be manageable via right-click context menu (remove, set permanent/temporary, adjust width/depth) without any application instability.
Steps to reproduce
Launch AetherSDR 0.7.10 on macOS.
Connect to a FLEX-6600 running firmware 4.1.5.39794.
Wait for the panadapter FFT/waterfall to render normally.
Click the +TNF button (Add Tracking Notch Filter) in the spectrum overlay or relevant toolbar control.
AetherSDR crashes immediately.
Expected: A new TNF notch is created and rendered on the spectrum. Actual: Application terminates with a crash.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: macOS
AetherSDR version: 0.7.10
Qt version: 6.7.3
Developer Notes
Based on the CLAUDE.md architecture and the TNF subsystem as documented, the following areas are the most likely sites of the crash:
Suspect source files
src/models/TnfModel.h / TnfModel.cpp This is the primary model responsible for TNF management (add/remove/drag/width/depth, permanent vs. temporary state). The crash likely originates here or is triggered by a signal emitted from here into the GUI layer. Key areas to audit:
The method that constructs and emits the tnf add freq= command — verify the frequency value passed in is always valid (non-zero, within band) before the command string is built.
The slot/handler that processes the radio's R|<hex_code>| response and extracts the new TNF ID — a malformed or missing response body could cause a null/empty ID to be stored and subsequently dereferenced.
CLAUDE.md notes that tnf remove and tnf set permanent= do not produce a corresponding status update from the radio, so optimistic updates are used. Verify that tnf add does return a reliable response and that the response handler is null-safe.
src/gui/SpectrumWidget.cpp / SpectrumWidget.h TNF overlays are rendered in SpectrumWidget. Potential crash sites:
The paint path that draws TNF notch rectangles — if TnfModel emits a tnfAdded signal before the model's internal list is fully populated, the overlay renderer may iterate over a partially initialized or empty-ID entry and dereference a null or dangling pointer.
Mouse event handlers for TNF dragging — if a TNF object is accessed before its ID is confirmed from the radio response, a use-after-free or null deref is possible.
src/gui/SpectrumOverlayMenu.cpp The right-click overlay menu wires the +TNF action. Verify the signal connection from the menu action to TnfModel::addTnf() (or equivalent) does not pass an uninitialized frequency argument, especially if the menu is invoked before a panadapter center frequency has been set in PanadapterModel.
src/models/RadioModel.cpp RadioModel owns the connection and routes commands. If the tnf add command is dispatched via commandReady but RadioConnection is in a transient state (e.g., still finishing the subscription sequence), the resulting sequence number mismatch could corrupt the response dispatch table and cause a crash in the response handler.
Logging categories to enable
In Help → Support, enable the following diagnostic categories before reproducing:
Category | Why -- | -- Protocol / Command | Captures the exact tnf add command string sent and the raw `R TNF / Model | Traces TNF ID assignment, model list mutations, and signal emissions — isolates whether the crash is in model update or GUI render Spectrum / GUI | Captures the paint and overlay rendering path — shows whether paintEvent is called with an invalid TNF entry Radio Connection | Confirms the TCP channel is healthy at the moment of the crash and that the sequence number round-trip completes
Collect the full log bundle with Send to Support immediately after the crash (or attach the log file from ~/.config/AetherSDR/ / the macOS equivalent under ~/Library/Application Support/AetherSDR/).
Potential root causes (in order of likelihood)
Null/uninitialized frequency passed to tnf add — If the panadapter center frequency has not yet been received from the radio when +TNF is clicked (race during connection setup), the command may be built with freq=0 or a garbage value. The radio may return an error response that the handler does not guard against, leading to a null TNF ID being inserted into the model and subsequently dereferenced.
Unguarded radio response parse in TnfModel — The tnf add response body contains the new TNF ID. If the response code is non-zero (error) or the body is empty/unexpected (possible firmware version mismatch — this radio runs 4.1.5.39794, not the reference 1.4.0.0), parsing may produce an invalid ID that is stored and later dereferenced during the first paintEvent.
Signal/slot wiring issue on macOS — The tnfAdded signal may be connected with Qt::DirectConnection in a context that is called from a non-GUI thread (e.g., the TCP receive thread in RadioConnection), triggering a SpectrumWidgetrepaint from off the main thread — undefined behavior that manifests as a crash on macOS where the graphics stack is stricter than Linux.
SpectrumOverlayMenu action connected to a dangling TnfModel pointer — If TnfModel is owned by RadioModel and the overlay menu retains a raw pointer, a reconnect cycle that destroys and recreates RadioModel (and thus TnfModel) would leave the menu's connection pointing to freed memory. Clicking +TNF after any reconnect would then crash immediately.
Firmware protocol difference — The FLEX-6600 at fw 4.1.5.39794 may return a different tnf status message format than the reference firmware (1.4.0.0 in CLAUDE.md). If the status key names differ (e.g., frequency vs freq), TnfModel::applyStatus() may silently skip updating the frequency field, leaving the object in a zero-initialized state that causes a divide-by-zero or out-of-range access in the spectrum renderer.
Protocol note for developers: Per CLAUDE.md's optimistic update policy, if tnf add does not produce a reliable S|tnf ... status echo on this firmware version, any optimistic list insertion should be filed as a separate [protocol] + [upstream] issue requesting FlexRadio add proper status feedback for TNF creation.
support-bundle-20260329-212907.tar.gz
support-bundle-20260329-212536.tar.gz
support-bundle-20260329-212223.tar.gz
support-bundle-20260329-211449.tar.gz
support-bundle-20260329-211051.tar.gz
support-bundle-20260329-210542.tar.gz
AetherSDRCrashReport.log
What happened?
Clicking the +TNF button (Add Tracking Notch Filter) in the spectrum overlay or toolbar causes AetherSDR to crash immediately. The crash is reproducible and occurs at the point of TNF creation — either before or immediately after the tnf add command is sent to the radio. No TNF notch appears on the panadapter, and the application terminates without a visible error dialog.
What did you expect?
Clicking +TNF should send a tnf add freq=<center_frequency> command to the FLEX-6600 over the TCP command channel (port 4992), receive a response with the new TNF's ID, and render a draggable notch filter overlay on the panadapter spectrum at the current center frequency. The TNF should be manageable via right-click context menu (remove, set permanent/temporary, adjust width/depth) without any application instability.
Steps to reproduce
Launch AetherSDR 0.7.10 on macOS.
Connect to a FLEX-6600 running firmware 4.1.5.39794.
Wait for the panadapter FFT/waterfall to render normally.
Click the +TNF button (Add Tracking Notch Filter) in the spectrum overlay or relevant toolbar control.
AetherSDR crashes immediately.
Expected: A new TNF notch is created and rendered on the spectrum. Actual: Application terminates with a crash.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: macOS
AetherSDR version: 0.7.10
Qt version: 6.7.3
Developer Notes
Based on the CLAUDE.md architecture and the TNF subsystem as documented, the following areas are the most likely sites of the crash:
Suspect source files
src/models/TnfModel.h / TnfModel.cpp This is the primary model responsible for TNF management (add/remove/drag/width/depth, permanent vs. temporary state). The crash likely originates here or is triggered by a signal emitted from here into the GUI layer. Key areas to audit:
The method that constructs and emits the tnf add freq= command — verify the frequency value passed in is always valid (non-zero, within band) before the command string is built.
The slot/handler that processes the radio's R|<hex_code>| response and extracts the new TNF ID — a malformed or missing response body could cause a null/empty ID to be stored and subsequently dereferenced.
CLAUDE.md notes that tnf remove and tnf set permanent= do not produce a corresponding status update from the radio, so optimistic updates are used. Verify that tnf add does return a reliable response and that the response handler is null-safe.
src/gui/SpectrumWidget.cpp / SpectrumWidget.h TNF overlays are rendered in SpectrumWidget. Potential crash sites:
The paint path that draws TNF notch rectangles — if TnfModel emits a tnfAdded signal before the model's internal list is fully populated, the overlay renderer may iterate over a partially initialized or empty-ID entry and dereference a null or dangling pointer.
Mouse event handlers for TNF dragging — if a TNF object is accessed before its ID is confirmed from the radio response, a use-after-free or null deref is possible.
src/gui/SpectrumOverlayMenu.cpp The right-click overlay menu wires the +TNF action. Verify the signal connection from the menu action to TnfModel::addTnf() (or equivalent) does not pass an uninitialized frequency argument, especially if the menu is invoked before a panadapter center frequency has been set in PanadapterModel.
src/models/RadioModel.cpp RadioModel owns the connection and routes commands. If the tnf add command is dispatched via commandReady but RadioConnection is in a transient state (e.g., still finishing the subscription sequence), the resulting sequence number mismatch could corrupt the response dispatch table and cause a crash in the response handler.
Logging categories to enable
In Help → Support, enable the following diagnostic categories before reproducing:
Category | Why -- | -- Protocol / Command | Captures the exact tnf add command string sent and the raw `R TNF / Model | Traces TNF ID assignment, model list mutations, and signal emissions — isolates whether the crash is in model update or GUI render Spectrum / GUI | Captures the paint and overlay rendering path — shows whether paintEvent is called with an invalid TNF entry Radio Connection | Confirms the TCP channel is healthy at the moment of the crash and that the sequence number round-trip completes
Collect the full log bundle with Send to Support immediately after the crash (or attach the log file from ~/.config/AetherSDR/ / the macOS equivalent under ~/Library/Application Support/AetherSDR/).
Potential root causes (in order of likelihood)
Null/uninitialized frequency passed to tnf add — If the panadapter center frequency has not yet been received from the radio when +TNF is clicked (race during connection setup), the command may be built with freq=0 or a garbage value. The radio may return an error response that the handler does not guard against, leading to a null TNF ID being inserted into the model and subsequently dereferenced.
Unguarded radio response parse in TnfModel — The tnf add response body contains the new TNF ID. If the response code is non-zero (error) or the body is empty/unexpected (possible firmware version mismatch — this radio runs 4.1.5.39794, not the reference 1.4.0.0), parsing may produce an invalid ID that is stored and later dereferenced during the first paintEvent.
Signal/slot wiring issue on macOS — The tnfAdded signal may be connected with Qt::DirectConnection in a context that is called from a non-GUI thread (e.g., the TCP receive thread in RadioConnection), triggering a SpectrumWidgetrepaint from off the main thread — undefined behavior that manifests as a crash on macOS where the graphics stack is stricter than Linux.
SpectrumOverlayMenu action connected to a dangling TnfModel pointer — If TnfModel is owned by RadioModel and the overlay menu retains a raw pointer, a reconnect cycle that destroys and recreates RadioModel (and thus TnfModel) would leave the menu's connection pointing to freed memory. Clicking +TNF after any reconnect would then crash immediately.
Firmware protocol difference — The FLEX-6600 at fw 4.1.5.39794 may return a different tnf status message format than the reference firmware (1.4.0.0 in CLAUDE.md). If the status key names differ (e.g., frequency vs freq), TnfModel::applyStatus() may silently skip updating the frequency field, leaving the object in a zero-initialized state that causes a divide-by-zero or out-of-range access in the spectrum renderer.
Protocol note for developers: Per CLAUDE.md's optimistic update policy, if tnf add does not produce a reliable S|tnf ... status echo on this firmware version, any optimistic list insertion should be filed as a separate [protocol] + [upstream] issue requesting FlexRadio add proper status feedback for TNF creation.
support-bundle-20260329-212907.tar.gz
support-bundle-20260329-212536.tar.gz
support-bundle-20260329-212223.tar.gz
support-bundle-20260329-211449.tar.gz
support-bundle-20260329-211051.tar.gz
support-bundle-20260329-210542.tar.gz