View Issue Details

IDProjectCategoryView StatusLast Update
0002899Ham Radio DeluxeBugpublic2018-09-28 21:42
ReporterK7ZCZ 
Assigned ToK7ZCZ 
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.888 
Summary0002899: Logbook: divide-by-zero encountered in callsign lookup when machine has no hardware perf counters
DescriptionA dump was submitted in ticket 508543 that shows this stack in the Logbook:

0:012> .ecxr
eax=00000002 ebx=08d94030 ecx=00000000 edx=00000000 esi=0a69e8ec edi=00000000
eip=002b88bb esp=0a69d4bc ebp=0a69d50c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
HRDLogbook!_alldiv+0x4b:
002b88bb f7f1            div     eax,ecx
0:012> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 0a69d4c4 001439c5 6676db40 00000002 00000000 HRDLogbook!_alldiv+0x4b [f:\dd\vctools\crt\crtw32\helper\i386\lldiv.asm @ 121] 
01 0a69d50c 006386e2 ff6a4d44 14fb8688 156564c8 HRDLogbook!CStopwatch::~CStopwatch+0x95 [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 67] 
02 0a69fb08 00696663 0a69fb30 14fb8688 00000001 HRDLogbook!CBackgroundProcessingThreadLookups::CountryLookup+0xfc2 [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 16707566] 
03 0a69fb70 00684f5e 00000001 ff6a4dcc 00000000 HRDLogbook!CDXCObject::PerformLookup+0xa3 [c:\ham radio\logbook\hrdlogbook\dxclusterobject.cpp @ 1243] 
04 0a69fbb0 002b1beb 0594d730 ff6a4da4 00000000 HRDLogbook!CDXClusterDlg::LookupThreadProc+0x10e [c:\ham radio\logbook\hrdlogbook\dxclusterdlg.cpp @ 358] 
05 0a69fbe8 002b1d13 00000000 0a69fc00 7745343d HRDLogbook!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 
06 0a69fbf4 7745343d 059336d0 0a69fc40 77ab9832 HRDLogbook!_threadstartex+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 
07 0a69fc00 77ab9832 059336d0 55b7ba6a 00000000 kernel32!BaseThreadInitThunk+0xe
08 0a69fc40 77ab9805 002b1c97 059336d0 00000000 ntdll!__RtlUserThreadStart+0x70
09 0a69fc58 00000000 002b1c97 059336d0 00000000 ntdll!_RtlUserThreadStart+0x1b


This stack shows a divide-by-zero error when we're computing the time elapsed for a database query to add to the logfile window.
TagsNo tags attached.
ModuleLogbook
Sub-ModuleCall lookup
Testing Beta Successful

Relationships

related to 0002845 closedWA9PIE V6.4.0.876 - Random crashes\Lockups\closing of LB and DM where both are affected at the same time. 

Activities

K7ZCZ

2018-09-18 08:31

manager   ~0006215

The timing code uses the QueryPerformanceCounter() and QueryPerformanceFrequency() APIs to measure the time elapsed. Calls are made to QPC before and after the database call, so the the elapsed ticks are found by subtraction. That number of ticks is converted to microseconds by division over the return from QPF(). This crash means that QPF() has returned zero.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms644905%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 says that it will return zero if hardware counters aren't available, but explains that "this will not occur on systems that run Windows XP or later". We can see the user is running a multi-core processor and Windows XP SP1, which was released in 2002 and is now more than 16 years old.

0:012> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
6.1.7601.18015 (win7sp1_gdr.121129-1432)
Machine Name:
Debug session time: Sat Sep  1 13:44:25.000 2018 (UTC - 7:00)
System Uptime: not available
Process Uptime: 0 days 0:00:19.000
  Kernel time: 0 days 0:00:02.000
  User time: 0 days 0:00:05.000


We might somehow still be getting a zero out of the function. Or, it's possible that two threads are racing to the initializer of a static local that holds the return value from QPF() for all uses of the CStopwatch timer class. Static initializers in Visual C++ 2013 aren't singleton thread safe; this is one of several reasons we should upgrade to Visual C++ 2018.

K7ZCZ

2018-09-18 08:42

manager   ~0006217

fixed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4351

g3ucq

2018-09-28 10:53

viewer   ~0006244

Unable to test

WA9PIE

2018-09-28 21:42

administrator   ~0006251

Resolved as part of the 888 build.

Issue History

Date Modified Username Field Change
2018-09-18 08:26 K7ZCZ New Issue
2018-09-18 08:30 K7ZCZ Relationship added related to 0002845
2018-09-18 08:31 K7ZCZ Note Added: 0006215
2018-09-18 08:42 K7ZCZ Assigned To => K7ZCZ
2018-09-18 08:42 K7ZCZ Status new => resolved
2018-09-18 08:42 K7ZCZ Resolution open => fixed
2018-09-18 08:42 K7ZCZ Note Added: 0006217
2018-09-28 07:50 K7ZCZ Fixed in Version => 6.4.0.887
2018-09-28 07:50 K7ZCZ Description Updated View Revisions
2018-09-28 10:53 g3ucq Note Added: 0006244
2018-09-28 21:40 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2018-09-28 21:41 WA9PIE Testing Not Started => Beta Successful
2018-09-28 21:41 WA9PIE Fixed in Version 6.4.0.887 => 6.4.0.888
2018-09-28 21:42 WA9PIE Status resolved => closed
2018-09-28 21:42 WA9PIE Note Added: 0006251