MessageQueue::pop() transfers ownership of the popped message to the
caller, but many handleInputMessages() implementations only deleted
the message when handleMessage() returned true. When a message was not
handled, ownership had already been transferred from the queue and the
message was leaked.
This was identified while investigating an ASAN leak in the audio
subsystem.
Update the applicable handleInputMessages() implementations to always
delete messages after handleMessage() returns. Unhandled messages are
also logged with the component and message identifier so unexpected
message routing is visible during debugging.
This change:
- Ensures every message popped from a queue has its ownership resolved.
- Prevents leaks when handleMessage() returns false.
- Makes unhandled messages visible instead of silently discarding them.
- Preserves the existing message handling logic and does not require
components to handle message types that are legitimately irrelevant
to them.
The changes are intentionally mechanical and limited to the common
message queue ownership and diagnostic pattern.
Signed-off-by: Robin Getz <rgetz503@gmail.com>
QMessageBox::information() and friends build the box on the stack, parent
it to the calling widget and run a nested event loop in exec(). If the
parent is closed while the box is open, which the Web API can do at any
time, the parent deletes the box and its children and the heap is
corrupted.
MessageDialog offers the same calls, but the box is heap allocated, given
Qt::WA_DeleteOnClose and shown rather than exec'd, so nothing runs a
nested event loop and the box owns its own lifetime. A box with the same
text as one already up is raised instead of a second being created.
The trade off is that information(), warning() and critical() return
immediately and cannot report which button was pressed. question() takes
a callback for the cases that need the answer.
Converts the call sites in the device, channel and feature GUIs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Update the PlutoSDR input, output, and MIMO GUIs to properly handle the
SDRangel device engine entering the StError state following an
asynchronous device failure.
Clear the affected start/stop controls without emitting their signals,
preventing the GUI from attempting to restart or otherwise operate on a
device that has become unavailable. Indicate the error state visually
and display the error message reported by the device engine.
Stop updating device-specific status information while the device engine
is in the error state, since the underlying PlutoSDR device and streaming
resources may already have been closed.
This keeps the GUI state synchronized with the SDRangel device engine
after asynchronous failures such as a disconnected or unavailable
PlutoSDR.
Signed-off-by: Robin Getz <rgetz503@gmail.com>
Query the PlutoSDR hardware for the current RX gain range and use it
to configure the GUI gain control dynamically.
The AD936x gain limits vary with LO frequency. Previously the GUI used
a fixed gain range, allowing users to select values that the hardware
would reject after changing bands. The gain slider now refreshes its
minimum, maximum, and step size whenever the device center frequency is
updated.
Also change the gain setting serialization to use a signed integer so
negative gain values are preserved for operating modes that support
them.
Changes include:
- Add DevicePlutoSDRBox::getGainRange() to read
in_voltage0_hardwaregain_available.
- Expose gain range through PlutoSDRInput.
- Refresh GUI gain limits when the device frequency changes.
- Avoid unnecessary widget updates when limits are unchanged.
- Store/restore gain as a signed value.
- Add default RX gain limit constants for fallback when the device
cannot provide its range.
Signed-off-by: Robin Getz <rgetz503@gmail.com>
screen when screen orientation changes.
Add DialPopup to allow dials to adjusted with a slider, which is easier
on touchscreens.
Add TableTapAndHold to support table context menus on touchscreens.
This will use the RF bandwidth from the device, which is different
between AD9363 and AD9364.
Things are now managed like the device likes - analog low pass bandwidth
is RF (complex) bandwidth, not baseband single I or Q bandwidth.
Signed-off-by: Robin Getz <robin.getz@analog.com>
When updating firmware, the devices which have AD9364s on them, get
reset to the default of a AD9363 (tuning range of 325 to 3800 MHz).
SDRAngel assumes a AD9364, and the GUI allows you to set LO settings
that the firmware doesn't support.
This ensures that does not happen, by going out to the hardware, and
querying the device to set the min/max limits on LO.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Edouard Griffiths
Robin Getz
Jon BenistonandClaude Opus 5
Daniele Forsi
Robin Getz