|
|
Also for Ticket #768428 Added a 2nd Minidump with this Mantis ID, please look at both |
|
|
Fix is out for review with this shelve set: https://hrdsoftware.visualstudio.com/HRD/_versionControl/shelveset?ss=fix%20cluster%20crash%3Bmikeblas%40msn.com |
|
|
Fixed with this checkin: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/3937 |
|
|
Tested with double click on cluster row with ALE open, as well as, right click on cluster row and select 'New ALE Window'. In both cases new ALE window is opened as is populated with lookup details. Fixed! |
|
|
This not fixed for me aas v.798 crashes every time I right click a cluster spot. See Mantis 2613 |
|
|
Same has John - here is my dump file. It does not matter if I right click on a spot and open an ALE or open an ALE in Logbook both crash as soon as you click on anything in the ALE window. HRDLogbook_20180402_190041.mdmp (754,150 bytes) |
|
|
Both the W4ASE minidump added here and the minidump that G3UCQ added to 2613 end up at the callstack below. I just made a mistake in cleaning up some code surrounding some of the other callsign lookup work I did; it's an easy fix and checked in with this change: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4015 0:028> kb *** Stack trace for last set context - .thread/.cxr resets it # ChildEBP RetAddr Args to Child 00 19aff6a8 532fab39 00000000 19aff6d4 19aff6f0 HRDLogbookCallsignLookup!CXMLMgr::AddAttribute+0x11b [c:\ham radio\hrdcommon\xmlmgr.cpp @ 1916] *** WARNING: Unable to verify checksum for HRDLogbook.exe 01 19aff8fc 017256d5 01aa4364 00020002 1ad129c8 HRDLogbookCallsignLookup!HRDLogbookCallsignLookupW+0xce9 [c:\ham radio\logbook\hrdlogbookcallsignlookup\hrdlogbookcallsignlookup.cpp @ 3973] 02 19aff920 01725b0e 002705e6 00020002 1827f6ac HRDLogbook!CLibBackgroundProcessingThread::CallsignLookup+0x35 [c:\ham radio\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 508] 03 19aff964 0181dac0 4d080048 1830ec30 1ac35118 HRDLogbook!CLibBackgroundProcessingThread::DoWork+0xde [c:\ham radio\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 206] 04 19aff98c 0181da06 4d08000c 012d2227 1830ec30 HRDLogbook!CThinThread::Run+0x80 [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 178] 05 19aff9c8 012d217b 182e3638 4d0803c4 012d2227 HRDLogbook!CThinThread::Start+0x46 [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 226] 06 19affa00 012d22a3 012d2227 19affa20 75858654 HRDLogbook!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376] 07 19affa0c 75858654 1830ec30 75858630 392c5c3a HRDLogbook!_threadstartex+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354] 08 19affa20 77bc4a77 1830ec30 3b65e59c 00000000 kernel32!BaseThreadInitThunk+0x24 09 19affa68 77bc4a47 ffffffff 77be9ea8 00000000 ntdll!__RtlUserThreadStart+0x2f 0a 19affa78 00000000 012d2227 1830ec30 00000000 ntdll!_RtlUserThreadStart+0x1b |
|
|
V.799 Logbook hangs here when: 1. Create ALE from DX Cluster spot (right-click) 2. Add the log entry from the ALE thus created. 3. Logbook hangs with the pale screen of impending death DMP file taken and uploaded to \Dropbox\Ham Radio Deluxe as K6MKF HRDLogbook 20180403.zip Also, while in the 'Not Responding' state, the Logbook process is acquiring .2MB of memory every second, according to Task Manager. |
|
|
I allowed the 'Not Responding' Logbook to run for a few hours. Memory usage grew to over 400MB and continued to grow. Killed it with Task Manager.
K6MKF Logbbok Memory Useage post-hang.JPG (22,592 bytes) |
|
|
The minidump described by K6MKF is a live-lock condition that is a side-effect of the design flaw described in Mantis 2098. It is not a new issue, nor is it related to this issue. |
|
|
Works for me in build 799 |
|
|
My concern here is that I am seeing this issue with v.799 on a very generic Windows 10 Home 64-bit implementation, which is likely a common one among our Users. If I have some sort of configuration error, I'd like to know what it is so it can be corrected and I can then achieve the results that Ferry, PD9FER, and others are seeing. If my HRD and Windows configurations are correct, then perhaps there is actual issue with Logbook that needs to be resolved before this Beta moves toward a release. |
|
|
K6MKF, if you're referring to the hang that you're having, then that's not a new issue. It's being tracked by Mantis 2098, and we'll work on it soon. If you're referring to the crash that others have reported in this issue, then please provide the steps that you're executing in order to realize the crash, as well as a matching minidump, and I can have a look. It would help me track and manage issues if you could please clearly identify your comments by using the corresponding Mantis issue for communication. If you're not sure which issue to use, opening a new issue is almost always better than adding information to the wrong one. Thanks! |
|
|
I think I've managed to confuse myself, as well as others. Here's what I think understand so far: Mantis # 0002652 - which is about a hang with Logbook and DM-780 and the IP Server under v.6.4.0.794. This was bug was opened as a result of this support ticket: IP Server hangs - Rig Control restart fixes [#160414] My notes above, here on 0002580, are referring to Beta v.799 Logbook hanging whenever I attempt to add a log entry via the Logbook ALE screen. Then I opened Mantis 0002653 just about my Logbook v.799 issue, as my issue with Logbook v.799 does not seem to fix well with 0002580. My personal email is mike.flowers@gmail.com and my cell is 408-307-8258 if you want to chat directly. |
|
|
K6MKF - do you consider this item fixed as described in this specific Mantis issue? |
|
|
>>> As the title says, when clicking on cluster spots to get them in the ALE and change the VFO to the spots frequency a crash happens. In as much as the ALE window is created and populated, and the VFO changes, this is fixed. However, any subsequent attempt to use the resulting ALE window to record a log entry, or to use an 'Add' ALE window to do so, results in a hang of Logbook as reported in Mantis 0002653. This is what I am consistently encountering with v.799. |
- Anonymous
