I don't see how HRD should be able to crash WSJTX except with a bad response
and non-robust code in the HRD transceiver backend.
But the log I saw doesn't show a bad response and the section of code in HRD
looks bullet proof.
Crashing is a sign of a segmentation fault which is either a NULL pointer or a
"bad" pointer.
Changing the hamlib version might change the stack allocation and is the only
way hamlib could affect HRD operation since Hamlib is a DLL and cannot
interfere directly with the HRD code in WSJTX which is static. The stack would
be the only common denominator.Hamlib calls aren't even being done when the HRD
rig is selected.
Mike W9MDB
On Thursday, July 28, 2022 at 04:30:08 AM CDT, Uwe, DG2YCB via wsjt-devel
<wsjt-devel@lists.sourceforge.net> wrote:
Hi,
For those of you who have problems with occasional program crashes, I can
recommend the following:
- Download this "wsjtx_log_config.ini" file and save it to your log
directory (for Linux, put it in ~/.config):
https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0-rc2/Tests/wsjtx_log_config.ini.
It enables trace logging, so that we can see every "event".
- Close WSJT-X, start it once again, and reproduce the error (in this case,
let WSJT-X run until the program crashes).
- On your desktop appears a new "logs" folder, and two files in it are
created: "WSJT-X_RigControl.log" and "wsjtx_syslog.log". The first one is
relevant to detect hamlib issues, but especially the latter is helpful to
detect any abnormal behavior (i.e. abnormal termination).
- Open the "wsjtx_syslog.log" file with a text editor, copy the last 20 or
25 lines of this file and send it to me. Experienced users can, of course,
already analyze themselves what causes the crash.
- Then delete (or rename) the "wsjtx_log_config.ini" file again, because due
to the trace logging the two .log files grow quickly in size.
- Delete the "logs" folder if you don't need it anymore.
Perhaps also helpful to know: I recently did the same procedure with an OM who
also reported occasional sudden program crashes. It turned out that HRD caused
the crashes for him.
73 de Uwe, DG2YCB
Am 28.07.2022 um 10:28 schrieb Dennis W1UE via wsjt-devel:
Mike Green found the same as you. If I just deleted the JT9 process, it still
didn’t work with N1MM. I have to restart the computer to again operate.
UE
On Wed, Jul 27, 2022 at 21:54 mpcorey--- via wsjt-devel
<wsjt-devel@lists.sourceforge.net> wrote:
Thanks Dennis, it sounds very similar to what I’m experiencing. Just this
evening, while calling CQ on 40, it has crashed three times. Each time I open
task manager and find the JT9 process, end it, and it will restart. Although in
once instance it crashed again within seconds of restarting. I’m not getting
the error messages though, like I did with 2.6rc1, unless I try and restart the
program without first ending the jt9 process.
From: Dennis W1UE via wsjt-devel <wsjt-devel@lists.sourceforge.net>
Sent: Wednesday, July 27, 2022 8:40 PM
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Cc: Dennis W1UE <egan.denni...@gmail.com>
Subject: Re: [wsjt-devel] V. 2.6 Error and Crash
Mike
I wrote this up and submitted it a week ago. I could not find any sequence of
events to cause the WSJT window to suddenly close. I found it took anywhere
from 15min to 3 hrs between crashes. I also get a TCP error when it closes, as
I have wsjt mated to N1mm+ for logging.
Dennis W1UE
On Wed, Jul 27, 2022 at 20:26 mpcorey--- via wsjt-devel
<wsjt-devel@lists.sourceforge.net> wrote:
So I posted to this list a few weeks ago about the problem with 2.6rc1 suddenly
crashing, and to restart ending a JT9 process through task manager. Last week,
prior to the release of rc2, this problem was occurring about 2 times per day
while I was on an Iota activation. So, when I returned home, I downloaded rc2
to the main station computer. The problem is still occurring, just had a crash
and “end JT9 process” fix to restart it. I recall others mentioning they
experienced this, has anyone else had it happen with rc2? Is this a software
bug? Or something to fix on the operator end?
Thanks,
Mike, KI1U
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
