View Issue Details

IDProjectCategoryView StatusLast Update
00031582 - Next Dev List (Holding Area)Bugpublic2020-07-02 02:11
ReporterK7ZCZAssigned To 
Status newResolutionopen 
Summary0003158: Changing radio control slider name causes crash in Rig Control when Logbook has old name in Radio pane layout
DescriptionWe've changed slider names in Rig Control with impunity. Turns out, that practice destabilizes the product because some code doesn't check to see if slider names are invalid before performing lookups of the names.

Steps To Reproduce1) Start up Rig Control.
2) Start Logbook, get them connected.
3) Edit the Radio Pane in Logbook to include the "AF Gain" control for the connectd radio.
4) Save the layout.
5) Close Logbook and Rig Control.
6) Edit the Rig Control application to use a different name for "AF Gain", like "AF Gain NEW NAME HERE".
7) Rebuild the Rig Control application.
8) Start Rig Control again
9) Start Logbook, get them connected again.

BUG#1) When Logbook starts, Rig Control will crash.

The culprit is an un-checked call to CRadioOptions::GetAdvancedIndex(). Several such calls exist in CRadioView::HandleGet(), which is the function that tries to handle commands sent from external clients to Rig Control. The lookup for "AF Gain" fails. The index returned from GAI() is invalid, then, but still used in subsequent calls. Those calls walk unowned memory and the application crashes.

TagsNo tags attached.
ModuleRig Control
Sub-ModuleRadio Support
TestingNot Started



2019-02-04 18:18

developer   ~0007257

I've added some defensive code with this checkin:

With that change in place, the apps won't get sick anymore. However, the broken slider control remains. The user won't be able to move it, it just sits there. They'll probably eventually figure out that they can delete it and replace it with the right control with a new name. But I think we can do a bit better. At startup (or at connection time) the Logbook can search the available controls to make sure they all match and issue a warning that they'll be removed... then remove them. This won't happen often (hopefully), so I don't think we're obliged to make anything terribly elegant or complete. I feel that it's adequate to just explain what's going on, and fix up the issue.

Issue History

Date Modified Username Field Change
2019-02-04 16:05 K7ZCZ New Issue
2019-02-04 18:18 K7ZCZ Note Added: 0007257
2019-02-10 22:15 WA9PIE Severity minor => crash
2019-02-10 22:15 WA9PIE Description Updated View Revisions
2019-02-10 22:15 WA9PIE Steps to Reproduce Updated View Revisions
2020-07-02 02:11 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)