View Issue Details

IDProjectCategoryView StatusLast Update
0003309Ham Radio DeluxeBugpublic2019-11-08 02:31
ReporterKB3NPHAssigned ToK7ZCZ 
PriorityhighSeveritycrashReproducibilityhave not tried
Status closedResolutionreopened 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003309: Customer complaining about last 3 HRD releases constantly crashing.
DescriptionTicket #428706 - Customer says that with the last 3 updates he has been experiencing system crashes when running HRD. He has provided 4 dump files that were created when his system crashed.

The dump files are in the Mantis 3309 folder in the Dumps on G-drive. Customer is using a K3, Windows 7 64-bit with 6GB Ram. Currently have HRD V6.5.0.207 installed.


TagsNo tags attached.
ModuleAll
Sub-Module(select)
Testing Beta Successful

Activities

K7ZCZ

2019-05-06 20:35

administrator   ~0007914

Are any repro steps available?

K7ZCZ

2019-05-07 00:05

administrator   ~0007917

Each of the dumps show a crash in the IPListener command handler, like this, for example:

0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 (Inline) -------- HamRadioDeluxe!ATL::CStringData::Release+0x17 [c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\atlmfc\include\atlsimpstr.h @ 90] 
01 (Inline) -------- HamRadioDeluxe!ATL::CSimpleStringT<wchar_t,0>::{dtor}+0x1a [c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\atlmfc\include\atlsimpstr.h @ 262] 
02 (Inline) -------- HamRadioDeluxe!ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >::{dtor}+0x1a [c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\atlmfc\include\cstringt.h @ 1295] 
03 003af474 00f2d5d3 HamRadioDeluxe!ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >::`scalar deleting destructor'(void)+0x1d
04 (Inline) -------- HamRadioDeluxe!DestructElement+0xd [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\elements.h @ 55] 
05 003af488 00f2cf99 HamRadioDeluxe!_DestructElements(class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * pOldData = 0x0461e6e0 "", int nCount = 0n0)+0x1d [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\array_s.cpp @ 50] 
06 003af8c4 00e2dae5 HamRadioDeluxe!CStringArray::~CStringArray(void)+0x48 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\array_s.cpp @ 80] 
07 003af9a0 00f248aa HamRadioDeluxe!CMainFrame::OnListener(unsigned int wParam = 0, long lParam = 0n94745720)+0xae5 [c:\hrd65\hamradiodeluxe\mainfrm.cpp @ 5052] 
08 003afa70 00e2fa38 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = 0xc231, unsigned int wParam = 0, long lParam = 0n94745720, long * pResult = 0x003afab8)+0x803 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2698] 
09 003afa98 00f259af HamRadioDeluxe!CXTPCommandBarsSiteBase<CMDIFrameWnd>::OnWndMsg(unsigned int message = 0xc231, unsigned int wParam = 0, long lParam = 0n94745720, long * pResult = 0x003afab8)+0x68 [c:\hrd65\codejock software\mfc\xtreme toolkitpro v18.6.0\source\commandbars\xtpframewnd.h @ 204] 
0a 003afabc 00f20870 HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0xc231, unsigned int wParam = 0, long lParam = 0n94745720)+0x2d [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2099] 
0b 003afb30 00f2102b HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x05a69418 {hWnd={...}}, struct HWND__ * hWnd = 0x000204ba, unsigned int nMsg = 0xc231, unsigned int wParam = 0, long lParam = 0n94745720)+0xc6 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 268] 
0c 003afb50 75ca62fa HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x000204ba, unsigned int nMsg = 0xc231, unsigned int wParam = 0, long lParam = 0n94745720)+0x34 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 417] 
0d 003afb7c 75ca6d3a user32!InternalCallWinProc+0x23
0e 003afbf4 75cb0d3f user32!UserCallWinProcCheckWow+0x109
0f 003afc2c 75cb0d65 user32!CallWindowProcAorW+0xab
10 003afc4c 0113dcfa user32!CallWindowProcW+0x1b
11 003afc94 75ca62fa HamRadioDeluxe!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x00000000, unsigned int message = 0, unsigned int wParam = 0, long lParam = 0n94745720)+0xaa [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\common\xtphookmanager.cpp @ 440] 
12 003afcc0 75ca6d3a user32!InternalCallWinProc+0x23
13 003afd38 75ca77c4 user32!UserCallWinProcCheckWow+0x109
14 003afd98 75ca788a user32!DispatchMessageWorker+0x3b5
15 003afda8 00f32804 user32!DispatchMessageW+0xf
16 003afdb8 00f32ecc HamRadioDeluxe!AfxInternalPumpMessage(void)+0x3e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
17 003afdd4 01327293 HamRadioDeluxe!CWinThread::Run(void)+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 629] 
18 003afdec 0106f443 HamRadioDeluxe!AfxWinMain(struct HINSTANCE__ * hInstance = 0x00d50000, struct HINSTANCE__ * hPrevInstance = 0x00000000, wchar_t * lpCmdLine = 0x0047241a "", int nCmdShow = 0n1)+0x93 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 61] 
19 (Inline) -------- HamRadioDeluxe!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
1a 003afe38 7566343d HamRadioDeluxe!__scrt_common_main_seh(void)+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
1b 003afe44 771a9802 kernel32!BaseThreadInitThunk+0xe
1c 003afe84 771a97d5 ntdll!__RtlUserThreadStart+0x70
1d 003afe9c 00000000 ntdll!_RtlUserThreadStart+0x1b


Luckily, the dump has the parameter memory and we can see that the message being handled is a request to "get slider-pos" ofr the "RF power (Low)" slider on a K3 radio; and for a few more sliders in the same request::

0:000> dx -r1 ((HamRadioDeluxe!MSG_LISTENER *)0n94745720)
((HamRadioDeluxe!MSG_LISTENER *)0n94745720)                 : 0x5a5b478 [Type: MSG_LISTENER *]
    [+0x000] m_strMessage     : "[618] get slider-pos K3 RF~power~(Low)	[618] get slider-pos K3 RF~power~(High)	[618] get slider-pos K3 Filter~Shift	[618] get slider-pos K3 Filter~Width	[618] get dropdown-text {Mode~A}	[618] get dropdown-text {Mode~B}	[618] get dropdown-text {Message}	[618] get button-select Test	[618] get button-select ATU~Tune	[618] get button-select ANT1	[618] get button-select ANT2" [Type: ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >]
    [+0x004] m_strReply       [Type: ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >]
    [+0x008] m_hEvent         : 0x57c [Type: void *]


The m_strMessage shows the query message with no problem. The m_strReply string seems like it contains a bogus value, however; at the very least, we don't have that memory and can't see what response might have bene built. The crash is in the desctructor of the CStringArray classes the application keeps locally, so it's conceivable that a bad return value in the message is getting added to the array and the first time it's touched is actually in that destructor.

The Locals display in Windbg seems to have some data that doesn't quite match the string we see in the above MSG_LISTENER dump, however:

0:000> .frame 0n7;dv /t /v
07 003af9a0 00f248aa HamRadioDeluxe!CMainFrame::OnListener+0xae5 [c:\hrd65\hamradiodeluxe\mainfrm.cpp @ 5052] 
003af95c          class CMainFrame * this = 0x05a69418
003af9a8          unsigned int wParam = 0
@esi              long lParam = 0n94745720
003af928          class COwnStringArray astrMessages = class COwnStringArray
003af97c          class CWnd * pWnd = 0x08210048 {hWnd={...}}
<unavailable>     class MSG_LISTENER * pMsg = <value unavailable>
003af958          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strAllMessages = "[618] get frequencies"
003af914          class COwnStringArray astrReplies = class COwnStringArray
<unavailable>     int nMsg = <value unavailable>
003af970          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strMessage = "[618] get frequencies"
003af974          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strLowercase = "ws\syswow64\psapi.dll"
003af8dc          class CFileVersion fv = class CFileVersion
003af968          struct __POSITION * posDoc = 0x003af9b0
003af984          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strReply = "溙ij"
<unavailable>     class CDocument * pDoc = <value unavailable>
003af954          struct __POSITION * posView = 0x003af9c4
003af980          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strText = ":Ŗ"
<unavailable>     class CRadioView * pView = <value unavailable>
003af980          class COwnString strHeading = class COwnString
<unavailable>     class CDocument * pDoc = <value unavailable>
003af94c          struct __POSITION * posDoc = 0x00000229
<unavailable>     class CRadioView * pView = <value unavailable>
003af948          struct __POSITION * posView = 0x000204b6
<unavailable>     int nContext = <value unavailable>
003af960          struct __POSITION * posDoc = 0x00000000
003af988          class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strTemp = "get frequencies"
<unavailable>     int nSpace = <value unavailable>
<unavailable>     class CDocument * pDoc = <value unavailable>
003af940          struct __POSITION * posView = 0x00000000
<unavailable>     class CRadioView * pView = <value unavailable>


Specifically, strAllMessages is just "get frequencies", which doesn't occur in the MSG_LISTENER input string. This implies that the code is actually processing a different MSG_LISTENER structure than we actually see on the stack.

Unfortunately, the code here is typical of the HRD message passing structure: memory is allocated on the heap, and a pointer for it is used to PostMessage() some other window. In this case, the poster waits 5 seconds before giving up and doesn't delete the allocated memory. However, if the poster thinks the event in the message structure is signalled, it will indeed delete the memory.

One possible cause of the crash is a very simple race. The next-to-last statement in CMainFrame::OnListener() sets the event the poster is waiting for. The incoming message include CStrings (which do reference counting and data sharing). The event is signalled, so the poster deletes memory. The CStringArray objects still hold references to the original CStrings (becaues of copy-on-write sharing) and end up trying to investigate and then free the memory in question. But they can't -- it's been deleted -- and they crash.

Sure enough, if we check the thread inside IPThread (which, in this case, is the sender) we find that it's done processing this call and busy trying to select() for the next command:

  10  Id: 1120.16d4 Suspend: 0 Teb: 7efac000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 060bd688 72f117cd 00000568 00000001 060bd6b0 ntdll!NtWaitForSingleObject+0x15
01 060bd6c8 72f16d20 00000568 00000550 00000001 mswsock!SockWaitForSingleObject+0x3a
02 060bd7b4 75d9673e 00000040 060bd8b0 00000000 mswsock!WSPSelect+0x3a6
03 060bd834 00e15fcc 00000040 060bd8b0 00000000 ws2_32!select+0x494
04 060bf9d8 00e15ab8 a73fe907 00e15a40 01581338 HamRadioDeluxe!CIpThread::ProcessConnection+0x10c [c:\hrd65\hamradiodeluxe\iplistener.cpp @ 996] 
05 (Inline) -------- -------- -------- -------- HamRadioDeluxe!CIpThread::ReEnterObject+0x17 [c:\hrd65\hamradiodeluxe\iplistener.cpp @ 792] 
06 060bfa0c 0130fe3e 0053a7c8 a73fe943 00000000 HamRadioDeluxe!CIpThread::StartThreadPoint+0x78 [c:\hrd65\hamradiodeluxe\iplistener.cpp @ 771] 
07 (Inline) -------- -------- -------- -------- HamRadioDeluxe!invoke_thread_procedure+0xd [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 82] 
08 060bfa48 7566343d 05bbf168 060bfa94 771a9802 HamRadioDeluxe!thread_start<void (__cdecl*)(void *)>+0x58 [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
09 060bfa54 771a9802 05bbf168 710bf5b4 00000000 kernel32!BaseThreadInitThunk+0xe
0a 060bfa94 771a97d5 0130fde6 05bbf168 00000000 ntdll!__RtlUserThreadStart+0x70
0b 060bfaac 00000000 0130fde6 05bbf168 00000000 ntdll!_RtlUserThreadStart+0x1b


I think straightening out this communication (or, at least, the memory ownership) might stabilize this problem. One fix might be to falsely scope the arrays and CStrings so that the destructors run before the event is actually signalled.

K7ZCZ

2019-05-20 21:23

administrator   ~0007940

Fixed with this checkin in the 6.7 branch
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4989

g3ucq

2019-09-02 08:14

viewer   ~0008493

No crashes for me apart from Mantis 0002152. (Bandscope)

WA9PIE

2019-09-07 08:41

administrator   ~0008518

I'm holding off on calling this validated. But if there's no other confirmation, I'll take John's observation as good.

WA9PIE

2019-09-13 23:57

administrator   ~0008546

Considered validated.

Issue History

Date Modified Username Field Change
2019-05-03 10:16 KB3NPH New Issue
2019-05-03 10:23 KB3NPH Description Updated View Revisions
2019-05-06 20:35 K7ZCZ Note Added: 0007914
2019-05-06 22:49 K7ZCZ Assigned To => K7ZCZ
2019-05-06 22:49 K7ZCZ Status new => resolved
2019-05-06 22:49 K7ZCZ Resolution open => unable to reproduce
2019-05-06 22:49 K7ZCZ Relationship added related to 0002732
2019-05-06 22:49 K7ZCZ Relationship added related to 0002808
2019-05-06 23:22 K7ZCZ Relationship deleted related to 0002732
2019-05-06 23:22 K7ZCZ Relationship deleted related to 0002808
2019-05-07 00:05 K7ZCZ Note Added: 0007917
2019-05-07 00:05 K7ZCZ Status resolved => new
2019-05-07 00:05 K7ZCZ Resolution unable to reproduce => reopened
2019-05-20 21:18 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2019-05-20 21:23 K7ZCZ Status new => resolved
2019-05-20 21:23 K7ZCZ Note Added: 0007940
2019-06-15 11:36 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)
2019-08-30 13:40 K7ZCZ Project 2 - Next Dev List (Holding Area) => 3 - Current Dev List
2019-08-30 15:16 K7ZCZ Fixed in Version => 6.7.0.226
2019-09-02 08:14 g3ucq Note Added: 0008493
2019-09-07 08:41 WA9PIE Note Added: 0008518
2019-09-13 23:57 WA9PIE Status resolved => closed
2019-09-13 23:57 WA9PIE Testing Not Started => Beta Successful
2019-09-13 23:57 WA9PIE Note Added: 0008546
2019-11-08 02:16 WA9PIE Fixed in Version 6.7.0.226 => 6.7.0.244
2019-11-08 02:31 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe