I've been running 2.6.0_(119)Gtk2 for quite a while with no isuues until today. I have 4 rigs set up and when I changed from one to the other I had no connection so I went to TRX control to change the port. TRX control froze so I finally had to force it closed. Ever since that I am getting the access violation error. So far I have tried:
1. Reinstalling 119, no luck
3. Installing 2.5.2 from the Mint repository, no luck
4. After finding I had an older Hamlib installed (4.3.1-build 2) I tried installing 4.5.5 which is the latest Hamlib. It appeared to install but 4.3.1-build 2 still shows in synaptic
I'm thinking that the older Hamlib I have installed may be the issue but I'm at a loss on what to do since Hamlib 4.5.5. Or, could my WSJTX some be influencing things?
Help!
73, Bill NZ0T
Same here, happened today as well. At startup it wanted to updated the DXCC list which I selected to do. After that No go. wont start and I can figure out where the backups are for this version. Not going where the 2.5.2 version placed them.
Hope Saku has a work around.
Jon
Jon
Hi Jon,
Well, at least I'm not alone in this!
73, Bill NZ0T
Hi guys,
I just want to report that after exporting ADIF file successfully closed the CQRLOG 2.5.2 without error. When I try to re-open it gives " Access violation error".
Deleted all .config/crqlog files, started from scratch ok but after reseting the software to check the rigctl same error came back.
The software was working fine up until now. No system updates or anything, just closed it normally and when re-open it it fail with this message.
I am seeing that other have it similar.
Debug gives :
edi@edi-pc:~$ cqrlog debug=1
(cqrlog:9094): GLib-GObject-WARNING **: 21:02:55.405: ../../../gobject/gsignal.c:2613: signal 'populate-popup' is invalid for instance '0x27e7560' of type 'GtkCellView'
(cqrlog:9094): GLib-GObject-WARNING **: 21:02:55.405: ../../../gobject/gsignal.c:2613: signal 'populate-popup' is invalid for instance '0x27e7600' of type 'GtkCellView'
Cqrlog Ver:2.5.2 (001) Date:2021-02-12
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****
OS:
Linux version 5.15.0-87-generic (buildd@lcy02-amd64-011) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #97-Ubuntu SMP Mon Oct 2 21:09:21 UTC 2023
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$000000000041F853
$000000000045ED45
Same error this morning - Access violation.
In my case I was using CQRLOG 2.5.1. I happened to need to restart the software to get the RBN and Telnet working again (in the midst of the CQ World Wide DX Contest). When I selected to update the DXCC list upon restart was when everything went wrong. I wonder if something very recently added to that list might be at issue?
I think the problem is not so in the details but some general issue, CQRLog was working whitout any issue for years and now in a same moment few not linked users have the same issue...strange.
I forgot to say that I am running latest linux mint distro, but nothing was updated or changed in the system before the error appears, just close it and few minutes later when I want to re open it, this error appears.
I'm also running Linux Mint 21.2. I have Timeshift set to take a daily snapshot of my system. Just now, out of curiosity, I restored my system back to yesterday's snapshot. Same problem.
I'm also running CQRLOG version 2.6.0, in case it's of interest to anybody reading this.
Here's my debug
bill@bill-OptiPlex-3010:~$ cqrlog debug=1
Cqrlog Ver:2.6.0_(119)_Gtk2 Date:2023-10-03
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=NR PARAMETER ****
*** Parameter -h or --help for details ***
OS:
Linux version 5.15.0-89-generic (buildd@bos03-amd64-016) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #99-Ubuntu SMP Mon Oct 30 20:42:41 UTC 2023
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$000000000041FB43
$000000000045D215
I hate to hijack a thread, but I started having the same issue a few minutes ago.
Everything's been fine. Logged 5 QSO's this afternoon, and all of a sudden I
have this access violation. I'll be watching to see if anybody finds a fix.
I've been using CQRLOG heavily over this weekend for the CQ World Wide DX Contest, and it just happened to me as well (about an hour ago) when I restarted the software. Only change for me on Debian 11 was updating the DXCC list.
Good morning from coffee table.
Here we have -17C this morning.
Forum is filled with messages about crashed Cqrlogs. Freezing like air outside.
Some of you report it happens after dxcc update. Some not.
Looking your debug dumps it seems to be something related with GTK graphics engine. Most of you are using GTK3, while Cqrlog is made with GTK2.
It might be related to this if there has been a system update behind that is changed GTK3 backwards compatibility.
If it is related to this, QT5 verion users ( like me) should not notice anything.
If it is related to dxcc updates it should happen also with QT5 version.
Yesterday I played with one code update and did see offering of new dxcc but did not load it yet.
And I am running Fedora 37 with manual updates, so nothing did not change in background.
One I get myself started I will look at this issue to see is it related to dxcc update or GTK update behind.
It seems to happen in several versions of Cqrlog same way.
Do not panic! And first make a backup copy of ~/.config/cqrlog folder before doing anything else.
--
Saku
OH1KH
Hi Saku, thanks for info.
In my case, I have the same issue but I haven't let any automatic update to the system: I use Q4OS based on Debian 11 and the problem appear after a restart of CQRLog.
During the restart I was asked for a DXCC upgrade and, the next time I catch the "access violation" error at start. So, I've clicked "abort" and made a Backup of "~/config/cqrlog" dir.
I have also an installation of CQRLog on other unused PC: after work I would try su use my backed up dir on this PC, replacing his "cqrlog" dir: do you think it is a way to solve? All contest QSO are there... sigh!
Just from experience I tired to backup the config folder - remove the folder and copied to some other location. When started CQRLOG it found that it is a new installation, I started configurating it again but it works only the first time, when you start configure your CQRLOG and close it and re-open it crashes again with the same error.
Nothing updated or installed/removed in the system within those 5min when it was working and initial crash.
Hi
as it was stated in here https://www.cqrlog.com/node/3668 ( next thread to this one ) by oh1kh - deleting MASTER.SCP file solved the issue for me.
Lets hope this will not re-appear again.
Solved for me to! Thanks LZ4NT!
Deleting MASTER.SCP worked for me. Luckily my log survived but I did have to reconfigure RIGCTRL possibly because I updated to the latest Hamlib while trying to fix the issue. I WILL NOT download any new DX/Manager lists until Saku issues a fix!
73, Bill NZ0T
Hi Everyone,
I have figured out this issue and submitted a pull request to SAKU.
The problem is that new DXCC data was published, and the size of a specific file grew significantly. CQRLOG had a hard-coded limit for this file size that was exceeded, causing a buffer overflow.
To work around this in the meantime, you can revert your ~/.config/cqrlog/MASTER.SCP file to the previous version, or just truncate it to < 100000 lines. I have attached a MASTER.SCP.txt file you can use in the meantime to get up and running:
1. mv ~/.config/cqrlog/MASTER.SCP ~/.config/cqrlog/MASTER.SCP.BROKEN
2. cp MASTER.SCP.txt ~/.config/cqrlog/MASTER.SCP
Start CQRLOG again and, if prompted, DO NOT download new dxcc data until Saku publishes the fixed version.
File:
Tnx W2KX deleted the MASTER.scp files from 11-24-2023 and newer. that solved issue.
Then went and unchecked to have the program to check for updates at startup.
73
Jon
Jon
WK2X - thanks! Nice job sleuthing this out!
Cheers!
Dave, N1KX
Just thought I'd chime in since I'd commented before. Thanks for the support everyone, and for being much smarter than I am!
Yesterday I installed the DXCC update when prompted at the start of CQrLog. Last nite closed down system and everything appeared normal. This afternoon I started up and got the error Access violation error. I followed this thread and thanks to WK2X's comments above I am back in business. Thank you all!!
73,
Jim, K4JIM
Nice description of the problem and thanks for posting the new abbreviated text file for replacing MASTER.SCP - it saved me and I am guessing everyone else a bit of time. Thanks, Bill!
73,
Steve, WA0A
The abbreviated text file worked for me, too.
Tnx,
Gary AF7M
I used rm ~/.config/cqrlog/MASTER.SCP and my CQRLOG is working fine now. Do I still need to add back the new file? If so where do I save it before running cp MASTER.SCP.txt ~/.config/cqrlog/MASTER.SCP?
73, Bill NZ0T
Hi Bill,
The master.SCP file is used for contest/call sign checking. If you don't care about that feature, you don't need that file to be present.
However, you should not take a new 'dxcc data' update until Saku or Petr publish an updated version of cqrlog with a permanent fix for loading that file. If you get a new file that's too long, it'll start crashing again. If you want the call check functionality in the meantime, just use the file I posted. You don't have to worry about the one you deleted.
I just posted the instructions to copy the file to the .broken extension so you could save a backup of it if you wanted, but it's not necessary.
Hi!
If you have a copy of old ~/.config/cqrlog folder and you need SuperCheck partial property you can dig out old MASTER.SCP file (smaller file size) and drop it to ~/.config/cqrlog
That way you get SuperCheck partial working but you do not have latest callsign list there.
Alpha version 2.6.0(120) has now ready compiled binaries with install script in https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
Also Official Cqrlog source is updated in https://github.com/ok2cqr/cqrlog prehaps we see also official release soon.
--
Saku
OH1KH
Thanks a lot Saku for coding 2.6.0(120), and update scripts, all is working great now
73, Tom SP4TB