View Issue Details

IDProjectCategoryView StatusLast Update
0003484Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterKC7FPFAssigned ToWA9PIE 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003484: Call sign lookup not working correctly or will freeze Logbook
Descriptionthis is related to the beta release of HRD release

Call sign lookup
When attempting to setup call sign look up. You are not able to adjust the order of the locations as to where to reference.
Also Log book will also freeze or lock up the LB. In order to clear this issue you have to close the Logbook and reset it in order to continue to use the logbook

Please see the included images for reference.
Steps To ReproduceStart the log book a normal
Attempt to look up a callsign
At this point no information is retrieved for the station information or call sign

TagsNo tags attached.
Sub-ModuleCall lookup
Testing Beta Successful


related to 0003482 new 3 - Current Dev List Improve timeout detection in call sign lookup operation completion 
related to 0003486 closedK7ZCZ Ham Radio Deluxe In V6.7.0.232 Callsign Lookup Pane does not populate 
has duplicate 0003187 closedWA9PIE Ham Radio Deluxe V6.5.0.187 to has problems with the Callsign Lookup Pane in the Logbook. 
child of 0003001 closedWA9PIE Ham Radio Deluxe Callsign lookup function does not appear to be working as designed 



2019-10-09 19:30


LB_1lookup.JPG (79,685 bytes)
LB_1lookup.JPG (79,685 bytes)
LB_1lookup2.JPG (26,023 bytes)
LB_1lookup2.JPG (26,023 bytes)
LB_1lookup3.JPG (66,031 bytes)
LB_1lookup3.JPG (66,031 bytes)


2019-10-12 11:55

administrator   ~0008789

Likely a duplicate of 3482


2019-10-16 09:23

administrator   ~0008832

Here's an example of the hang. It's caused by a deadlock.

1) Start the Logbook. Blank database.
2) Configure call sign lookup to use plus the three default sources
3) Configure as necessary
4) use the "Add" buttonm in the Logbook DB view toolbar to open the IDE
5) call sign of your choice; I used my owned
6) Press the "Lookup" button
BUG#1) App hangs

I finally trapped this in the debugger; it doesn't happen every time. On the main thread, PerformLookup() has completed and is sitting in a modified message loop (ugh!), repeatedly calling CheckCompleted(). It is waiting to get the lock, which is owned by the callsign lookup thread.

     ntdll.dll!_NtWaitForAlertByThreadId@8()	Unknown
     ntdll.dll!@RtlpWaitOnAddressWithTimeout@16()	Unknown
     ntdll.dll!RtlpWaitOnCriticalSection()	Unknown
     ntdll.dll!_RtlpEnterCriticalSectionContended@4()	Unknown
     ntdll.dll!_RtlEnterCriticalSection@4()	Unknown
     HRDLogbook.exe!CCriticalSection::Lock() Line 111	C++
     HRDLogbook.exe!CCriticalSection::Lock(unsigned long dwTimeout) Line 122	C++
>	HRDLogbook.exe!CSingleLock::Lock(unsigned long dwTimeOut) Line 108	C++
     HRDLogbook.exe!CSingleLock::CSingleLock(CSyncObject * pObject, int bInitialLock) Line 101	C++
     HRDLogbook.exe!CCallsignLookupComponent::CheckCompleted() Line 361	C++
     HRDLogbook.exe!CCallsignLookupComponent::PerformLookup(const wchar_t * pstrCompleteCallsign, const wchar_t * pstrPrefixCall, const wchar_t * pstrCallsign, const _SYSTEMTIME & stDate, const _SYSTEMTIME & stTime) Line 133	C++
     HRDLogbook.exe!CLogbookFull::PerformCallsignLookup(const wchar_t * lpCallsign, const CLogbookFull::eCallsignLookup eContext) Line 875	C++
     HRDLogbook.exe!CLogbookFull::OnStationLookup() Line 752	C++
     HRDLogbook.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void(CCmdTarget::*)() pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 77	C++
     HRDLogbook.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 372	C++
     HRDLogbook.exe!CDialog::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 85	C++
     HRDLogbook.exe!CWnd::OnCommand(unsigned int wParam, long lParam) Line 2800	C++
     HRDLogbook.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2113	C++
     HRDLogbook.exe!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 204	C++
     HRDLogbook.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2099	C++
     HRDLogbook.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265	C++
     HRDLogbook.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418	C++
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!CallWindowProcW()	Unknown
     HRDLogbook.exe!CXTPHookManager::HookWndProc(HWND__ * hWnd, unsigned int message, unsigned int wParam, long lParam) Line 440	C++
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!SendMessageWorker()	Unknown
     user32.dll!SendMessageW()	Unknown
     comctl32.dll!Button_NotifyParent(struct tagBUTN *,unsigned int)	Unknown
     comctl32.dll!Button_ReleaseCapture()	Unknown
     comctl32.dll!Button_WndProc()	Unknown
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!DispatchMessageWorker()	Unknown
     user32.dll!IsDialogMessageW()	Unknown
     HRDLogbook.exe!CWnd::IsDialogMessageW(tagMSG * lpMsg) Line 193	C++
     HRDLogbook.exe!CWnd::PreTranslateInput(tagMSG * lpMsg) Line 4607	C++
     HRDLogbook.exe!CDialog::PreTranslateMessage(tagMSG * pMsg) Line 80	C++
     HRDLogbook.exe!CXTPDialogBase<CXTPResizeDialog>::PreTranslateMessage(tagMSG * pMsg) Line 192	C++
     HRDLogbook.exe!CLogbookFull::PreTranslateMessage(tagMSG * pMsg) Line 4102	C++
     HRDLogbook.exe!CWnd::WalkPreTranslateTree(HWND__ * hWndStop, tagMSG * pMsg) Line 3379	C++
     HRDLogbook.exe!AfxInternalPreTranslateMessage(tagMSG * pMsg) Line 233	C++
     HRDLogbook.exe!CWinThread::PreTranslateMessage(tagMSG * pMsg) Line 777	C++
     HRDLogbook.exe!CHRDLogbookApp::PreTranslateMessage(tagMSG * pMsg) Line 1452	C++
     HRDLogbook.exe!AfxPreTranslateMessage(tagMSG * pMsg) Line 252	C++
     HRDLogbook.exe!AfxInternalPumpMessage() Line 178	C++
     HRDLogbook.exe!CWinThread::PumpMessage() Line 900	C++
     HRDLogbook.exe!CWinThread::Run() Line 629	C++
     HRDLogbook.exe!CWinApp::Run() Line 787	C++
     HRDLogbook.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47	C++
     HRDLogbook.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26	C++
     HRDLogbook.exe!invoke_main() Line 123	C++
     HRDLogbook.exe!__scrt_common_main_seh() Line 288	C++
     HRDLogbook.exe!__scrt_common_main() Line 331	C++
     HRDLogbook.exe!wWinMainCRTStartup() Line 17	C++
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown

The call sign Lookup thread is here, trying to send a message. It owns the crticial section in the lookup component because it has gone through the CheckCompleted() method and found all the results. The client is the ALE window, and its handler for OnCallsignLookupComponentFinished() is trying to set fields with the results, but SetText() causes a message to be sent to the main thread, which is blocked as above.

     win32u.dll!_NtUserMessageCall@28()	Unknown
     user32.dll!SendMessageWorker()	Unknown
     user32.dll!SetWindowTextW()	Unknown
     user32.dll!_SetDlgItemTextW@12()	Unknown
     HRDLogbook.exe!CWnd::SetDlgItemTextW(int nID, const wchar_t * lpszString) Line 153	C++
     HRDLogbook.exe!CLogbookWndQSL::SetField(unsigned int nID, const wchar_t * pstrText) Line 218	C++
>	HRDLogbook.exe!CLogbookFull::OnCallsignLookupComponentFinished() Line 945	C++
     HRDLogbook.exe!CCallsignLookupComponent::CheckCompleted() Line 424	C++
     HRDLogbook.exe!CCallsignLookupComponent::LookupResult(LookupDataSource lds, CLookupResult * pLUR) Line 355	C++
     HRDLogbook.exe!CLibBackgroundProcessingThread::CallsignLookupNew(ILookupResultsSink * pInterface, LookupDataSource lds, unsigned long dwTickStart, const ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > & strCallsign, const ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > & strUsername, const ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > & strPassword) Line 556	C++
     HRDLogbook.exe!CLibBackgroundProcessingThread::ProcessData(CLibBkgPacket * pPkt, const int nCount) Line 295	C++
     HRDLogbook.exe!CLibBackgroundProcessingThread::DoWork() Line 227	C++
     HRDLogbook.exe!CThinThread::Run() Line 189	C++
     HRDLogbook.exe!CThinThread::Start(void * pv) Line 228	C++
     HRDLogbook.exe!invoke_thread_procedure(unsigned int(__stdcall*)(void *) procedure, void * const context) Line 92	C++
     HRDLogbook.exe!thread_start<unsigned int (__stdcall*)(void *)>(void * const parameter) Line 115	C++
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown

We might decouple the ALE's OCLCF() handler by having it post a message to itself, but I think a better fix is to have CheckCompleted() release the lock before calling the handler. This'll fix fix all cases of this deadlock, though it still seems like the wait-for-completion code could be made more robust (per the related3482).


2019-10-16 16:07

administrator   ~0008835

This is a pretty broad report. I've fixed the deadlock that can happen for some clients of the new call sign lookup component, so I'm resolving this issue. While my fix works, we still don't handle actual timeouts in the lookup process so I'm leaving 3482.

The "does not work correctly" part of the issue seems to be related more to the Lookup Pane than the call sign lookup component itself, so I'll leave 3486 to speak for that issue.

Here's the change set:


2019-10-23 04:34

viewer   ~0008948

No problem for me.


2019-10-23 07:40

administrator   ~0008964

John and I have both validated.

Issue History

Date Modified Username Field Change
2019-10-09 19:29 KC7FPF New Issue
2019-10-09 19:30 KC7FPF File Added: LB_1lookup.JPG
2019-10-09 19:30 KC7FPF File Added: LB_1lookup2.JPG
2019-10-09 19:30 KC7FPF File Added: LB_1lookup3.JPG
2019-10-09 20:16 KC7FPF Relationship added child of 0003001
2019-10-10 07:49 KB3NPH Assigned To => WA9PIE
2019-10-10 07:49 KB3NPH Status new => assigned
2019-10-10 07:49 KB3NPH Description Updated View Revisions
2019-10-10 07:49 KB3NPH Steps to Reproduce Updated View Revisions
2019-10-10 07:49 KB3NPH Module => (select)
2019-10-10 07:49 KB3NPH Sub-Module => (select)
2019-10-10 07:49 KB3NPH Testing => Not Started
2019-10-11 18:35 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2019-10-11 18:36 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-10-12 11:55 K7ZCZ Relationship added related to 0003482
2019-10-12 11:55 K7ZCZ Note Added: 0008789
2019-10-12 17:06 K7ZCZ Relationship added has duplicate 0003187
2019-10-16 09:23 K7ZCZ Note Added: 0008832
2019-10-16 15:59 K7ZCZ Relationship added related to 0003486
2019-10-16 16:07 K7ZCZ Status assigned => resolved
2019-10-16 16:07 K7ZCZ Resolution open => fixed
2019-10-16 16:07 K7ZCZ Note Added: 0008835
2019-10-17 16:38 WA9PIE Module (select) => Logbook
2019-10-17 16:38 WA9PIE Sub-Module (select) => Call lookup
2019-10-21 17:01 K7ZCZ Fixed in Version =>
2019-10-23 04:34 g3ucq Note Added: 0008948
2019-10-23 07:40 WA9PIE Assigned To K7ZCZ => WA9PIE
2019-10-23 07:40 WA9PIE Status resolved => closed
2019-10-23 07:40 WA9PIE Testing Not Started => Beta Successful
2019-10-23 07:40 WA9PIE Note Added: 0008964
2019-11-08 02:12 WA9PIE Fixed in Version =>
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe