View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003158 | 2 - Next Dev List (Holding Area) | Bug | public | 2019-02-04 16:05 | 2020-07-02 02:11 |
| Reporter | K7ZCZ | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0003158: Changing radio control slider name causes crash in Rig Control when Logbook has old name in Radio pane layout | ||||
| Description | We'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 Reproduce | 1) 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. | ||||
| Tags | No tags attached. | ||||
| Module | Rig Control | ||||
| Sub-Module | Radio Support | ||||
| Testing | Not Started | ||||
|
|
I've added some defensive code with this checkin: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4806 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-02-04 16:05 |
|
New Issue | |
| 2019-02-04 18:18 |
|
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) |
