I have been using cqrlog with wsjt in FT8 mode for a long time, with no problems. I tried to use it today, and got an error dialog:
Invalid type cast.
Press OK to ignore and risk data corruption.
Press Abort to kill the program.
This message seems to appear as soon as wsjt sends out its UDP message containing the call signs that have been decoded during receive. If I press "OK" in the error dialog, cqrlog keeps running, but my QSOs are not logged.
I ran cqrlog with debugging enabled, but I'm not sure how to attach the debugging log to this posting. Should I email it somewhere, or put it up on Dropbox?
I tried grepping for the "Invalid type cast" message, but I didn't find that phrase in the cqrlog source, and I also didn't find it in the libraries shown by ldd, so I'm not sure where the message comes from.
Hi!
You can upload file with your message. Below text edit there is "File" and button "choose file" press that to select file. Then press button "Upload".
be sure you have suffix .txt in file. Start cqrlog from console:
cqrlog debug=1 > /tmp/debug.txt
After error close cqlog and upload /tmp/debug.txt with your next message.
I would also like to know does this error happen randomly or always? Perhaps caused by certain callsign on the band?
And what is your wsjt-x version (cqrlog version shows up in debug text).
--
Saku
OH1KH
Ok - I'll upload a debug file.
This bug happens 100%, and it even happens if I just monitor - I don't have to start a QSO. The error dialog pops up as soon as the 15 second FT8 time slice ends and WSJT-X decodes the received messages.
My WSJT-X is version v2.1.0.
It looks like the "Invalid type cast." probably comes from the Pascal runtime, or perhaps from Lazarus, but I am not a Pascal programmer. I tried using gdb, but that didn't show any exceptions. Is there a way for me to get more data for you?
Steve
File:
Hi Steve !
Is this debug really what it claims to be: Cqrlog Ver:2.4.0 (001) Date:2019-10-27
There is a line "Start adding richmemo lines" and if I go through 2.4.0 source with grep (grep -ni "richmemo" src/*.pas) I found only one hit "richmemo" And that is in comment, not in debug print.
I really wonder what package makers have done if you say that tar.gz files work ok !
We have enough problems already with package installs. Package makers should not add more of them with their own "tape and iron wire tuning".
As 2.4.0 does not have "Start adding richmemo lines" as debug text and richmemo is not used any more I can not help in "Invalid type cast." error,
I'm happy you have now a working version of cqrlog!
--
Saku
OH1KH
I accidentally uploaded the wrong log file. Attached please find one from 2.3.0.
By the way, the Fedora maintainer is in the process of packaging 2.4.0, and I'll give him feedback on his new build once I have a chance to test it.
File:
I just tested the new 2.4.0 Fedora-specific (RPM) build, and it works fine. So while I'm still curious as to why Fedora's older 2.3.0 build has a problem, I guess it doesn't really matter.
73,
Steve AC2XM
HI Steve!
I hope they did the build from current source, not from official release.
There is a serious bug in official 2.4.0(001) that prevents reports logging with JTDX. Source at Git is up to date and works.
--
Saku
OH1KH
I notified the downstream packager of the issue. Hopefully he will rebuild from the tip of your source tree. Do you plan to make a point release with the fix?
That fix is already in Petr's official source.
See commits: https://github.com/ok2cqr/cqrlog/commits/master
--
Saku
OH1KH
I just generated a patch from the release tag to master and applied it. New updates have been submitted for Fedora.
I'm not patching anything of significance, it's more likely different dependency versions or build flags.
The spec file and patches can be inspected here[1], and the latest build log for Fedora 31 seen here[2].
Thanks,
Richard
KF5OIM
[1] https://src.fedoraproject.org/rpms/cqrlog/tree/master
[2] https://kojipkgs.fedoraproject.org//packages/cqrlog/2.4.0/1.fc31/data/lo...
I tried downloading both cqrlog_2.3.0_amd64.tar.gz and cqrlog_2.4.0_amd64.tar.gz from github, and both worked properly - I did not see any error dialogs. I also cloned the source repo, built it, and tried out my build. It worked ok too.
So, this problem appears to be specifically in the cqrlog 2.3.0 Fedora-31 package. I've filed a bug with Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1770478
For now, I'll use your cqrlog_2.4.0 build. But I'd still like to know if there is a way to get more info than what is shown in the error dialog. It would be great if there was a way to identify the source file and line number where the invalid type cast is happening.
Steve