Access Violation with Mint 17.3

23 posts / 0 new
Last post
DO1YHJ
Access Violation with Mint 17.3

After Hours of running suddenly I got a Access Violation and cqrlog crashed. It didn't start any more.
cqrlog --debug=1

**** DEBUG LEVEL 1 ****

Loading libssl: /usr/lib/x86_64-linux-gnu/libssl.so
Loading libcrypto: /usr/lib/x86_64-linux-gnu/libcrypto.so
Loading libmysqlclient: /usr/lib/x86_64-linux-gnu/libmysqlclient.so
**************************
MySQL version: 5.5
**************************
**********************************
MySQL version assigned: 5.5
**********************************
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$0000000000428E95
$000000000045B995
TApplication.HandleException Access violation
Stack trace:
$0000000000428E95
$000000000045B995
Closing ini file ...

Edit:
mysql is running

mysqladmin -u root -p version
Enter password:
mysqladmin Ver 8.42 Distrib 5.5.53, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Server version 5.5.53-0ubuntu0.14.04.1
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 22 min 18 sec

Threads: 1 Questions: 106 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 0.079

F5JQF
Access Violation with Mint 17.3

Hi !, same trouble in my side. Yesterday all was ok but today "access violation"
cqrlog 2.02 (001)
linuxmint 17.3

73 Yves

Yves, F5JQF
CQRlog Ver.2.6.0_(126)_GtK2 / Hamlib 4.5.5 / Linux Mint 21.3 Cinnamon
..

DO1YHJ
Hmm. are you using WSJT-X 1.7

Hmm. are you using WSJT-X 1.7 in remote mode?
A few days ago, I installed WSJT-X 1.7 out of its PPA. It was running in combination with cqrlog without problems. Today I started cqrlog first, then wsjt-x remote out of cqrlog. It was running for a few minutes, then I started to answer a CQ Call. In that moment (Callsign was send to cqrlog), cqrlog crashed with the access violation. And will not start again.

What's the difference between yesterday and today in my system:
Yesterday a new Adobe Flash Plugin was installed and a new linux-lib-devc (new: 3.13.0-107.154 old: 3.13.0-106.153)
But after that, the system was running for hours without any problem.

73 Heinz-Juergen

oh1kh
Access violation

Hi !

Still using 1.9.0 with my additions but had this same trouble this morning.

[saku@minipc database]$ cqrlog --debug=1

**** DEBUG LEVEL 1 ****

Loading libssl: /usr/lib64/libssl.so
Loading libcrypto: /usr/lib64/libcrypto.so.1.0.2j
Loading libmysqlclient: /usr/lib64/mysql/libmysqlclient.so
**************************
MySQL version: 10.
**************************
**********************************
MySQL version assigned: 1.000000000000000000E+01
**********************************
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$000000000042067D
$000000000045C000
TApplication.HandleException Access violation
Stack trace:
$000000000042067D
$000000000045C000

Started this morning as normally. Update was offered. It was either qsl-mgr or dxcc, I do not remember. Accepted that.
After that had one qso with wsjt-x.
During that I was getting errors of data corruption all the time but passed them with ok. As it sometimes happens so with this 1.9.0 of mine.
Usually aswer OK then remove wxjt-x remote mode and start remote mode again helps. Without any troubles.

How ever this morning got plenty of those errors and finally could not log my wsjt-x qso because of error all the time.
Decided to restart program, but now it does not start any more just giving splash ("CW key") and the stops to Access violation.

Tried to restotre database, but it did not help.

Before trying anything else I decided to check this forum to see If someone else has same problem.
As it seems that this is not my problem alone I now suspect that qsl/dxcc update that I accepted this morning was the main reason for this.

Did you load update(s) today (or yesterday) ?

Now I have to start digging what is wrong...
MIght be hard to find out... it is over year since I last looked at the source code!

I hope someone finds the reason and fix before me :)

--
Saku
OH1KH

oh1mrr
I got hint from OH1KH and

I got hint from OH1KH and tested, it is DXCC tables update what breaks
whole prog. ALERT do not accept new dxcc tables. Using Fedora 25 and Cqrlog 2.0.2

<p>Jarmo</p>

DO1YHJ
Yes, that's it. Same problem

Yes, that's it. Same problem on a second machine. Running fine but after updating DXCC tables, it crashes.
The question is now, how to fix that issue without access to a running cqrlog?

73 Heinz-Juergen

oh1kh
Access violation

HI !

As quick fix , to get program running again, rename /home/your_username/.config/cqrlog to /home/your_username/.config/cqrlog_defunc

Start cqrlog. Now it does not complain.
It will ask are you running program first time.

If you have not separate mysql database in use you should say YES and restore qsos from ADIF backup.

If you have changed your mysql database so that it runs on another database server, or at same PC but as database
that does not shut down with cqrlog (this means mysql data is NOT in subdir .config/cqrlog/database) you must say NO.
In this case you have right away running cqrlog again (as I do :) )

Have not found real reason yet but it seems NOT to be inside database data. I restore faulty .config/cqrlog and
continue search.

--
Saku
OH1KH

--
Saku
OH1KH

DO1YHJ
Sorry, that did not work.

Sorry, that did not work. After starting with a new log, it wants to import new DXCC Tables. It crashes again after that.

73 Heinz-Juergen

oh1kh
Access violation

Do not accept load of DXCC. Say NO.

Bug is in DXCC update.
If you start as "clean" and do not allow update to DXCC it runs.

Then you can stop. Rename folder to .config/cqrlog_new
Restore your old, not working folder .config/cqrlog. (but save a copy of this folder!) Do not start program, it will not start.
Go to config/cqrlog.

Remove folders: call_data, ctyfiles, dxcc_data
Remove files: eqsl.txt, lotw1.txt, MASTER.SCP

Copy all those from "clean" started cqrlog's folder you renamed as .config/cqrlog_new to this
"not working" .config/cqrlog
Start program. It starts.
DO NOT ACCEPT DXCC or QSLmgr UPDATES.

We have to wait before they are fixed !

If you have a backup from yesterday you can copy those files and folders from there to get little bit more recent files.

--
Saku
OH1KH

--
Saku
OH1KH

DO1YHJ
Thnx. Everything is running

Thnx. Everything is running again with that old "new" configuration.

73 Heinz-Juergen

F5JQF
Access violation

Hi !.. many thanks for the solution. All is ok now for me. Have a good day.
Yves
 

Yves, F5JQF
CQRlog Ver.2.6.0_(126)_GtK2 / Hamlib 4.5.5 / Linux Mint 21.3 Cinnamon
..

DO1YHJ
Okay, it's running. After

Okay, it's running. After creating the new log, the download of QSL-Managers and DXCC Table is okay. But after starting cqrlog with that new log, you should not import the new DXCC Database. If you do that, it will crash again. QSL-Managers is okay.
By the way, what files are necessary for the configuration? I imported an older Configuration File and all seems okay, but i'm not sure, if i did same changes in that time.

73 de Heinz-Juergen

oh1kh
Faulty DXCC update

Yep!

Got some other things meanwhile, but now I have tested a little bit more.

Bug comes with DXCC update as we now know.

If you get stuck with not starting cqrlog it seems to be enough to remove only /home/your_username/.config/cqrlog/lotw1.txt
After that program starts.

Earlier I recommended remove some folders and files. For that I know that cqrlog was running after it few hours without problem. (while I was away).

Removing only lotw1.txt is not tested for long but it seems to be enough. At least manual log entry can be made (and removed).
Now I have to test with wsjt-x remote.

Anyway deleting only this one file gets you inside the program again.(do your backups!) When started it generates this file again.
It is a long file and a brief check does not show any differences. Maybe there is one unprintable character somewhere
in faulty file.

--
Saku
OH1KH

--
Saku
OH1KH

DO1YHJ
Seems to work. Quick check

Seems to work. Quick check with wsjt-x remote and my broken configuration with removed lotw1.txt shows no error. QSO in Log, upload to all Online Logs is working too. Looks okay for now.

73 de Heinz-Juergen

oz1gnn
Fedora 25

The quickfix by renaming lotw1.txt is also working here.

73 and happy new year de Christian

Vy 73 de oz1gnn

DL4DZ
Hi all,

Hi all,

had the same problem. I tried to rename "lotw1.txt" and it worked.
THANKS TO ALL

vy 73

Olaf, DL4DZ

n0op
wondering if waiting might be smart?

Hi all,

have the same problem. Got the same results exactly running debug.

What is the impact of taking the "lotw1.txt" file quickfix? I have many thousands of QSLs in the log from LOTW and I am not as comfortable with this software and playing with the files as I have only used CQRlog mid year last year and not as knowledgeable about the files purpose. I have backups from every time the log was shut down ... but then what is in LOTW.txt? Is it records of what foreign stations are members for Log Book of the World and some data on them or is it some records that are particular to my log entries?

ok2cqr
ok2cqr's picture
Re: wondering if waiting might be smart?

Hi,

I'm very sorry for late answer to this bug. I just released new version, it should fix the bug. Packages are already building on Launchpad.

Yes, deleting lotw1.txt file located in ~/.config/cqrlog is the quick fix.

73 Petr, OK2CQR

n0op
Re: wondering if waiting might be smart?

Quick response Petr! Thanks! I deleted the lotw.txt file and am back in operation but I take it from what I read that the lotw1.txt is a list of stations using lotw and that program src/dData.pas had a hard coded limit that the file exceeded when new calls were added.  So I assume I need a new version of the software in order to keep current on DXCC tables. I am currently shown as on 2.0.2 (001), What am I looking for in version to download and where?
I'm not looking at the source but normally wouldn't we check for the hard coded limit as the file is being loaded rather than keep loading past the limit or do I misunderstand your comment? (I am guessing we built an array and loaded the table into the array and went past the memory reserved for the array. )
 
(Sorry I'm still a newbee here) 
BTW what a great crew on the fourm! 
DO1YHJ ! thanks for helping me with what the lotw1.txt file is about and everyone else for getting me operational quick!
 

DO1YHJ
N0OP

If you are using a Debian Based Linux like Mint or Ubuntu:
The best way to be up to date is adding the PPA as shown here in the Download Section.https://www.cqrlog.com/downloadThat*s "override" the mostly older Versions, that will come with the default Distribution Software Pool and you will allways have the newest cqrlog.
You can also Download the *.deb Files and install them with a Double Click. i386 is for 32bit Linux Distribution, amd64 for the 64bit Version.
I didn't play with the Source Files or with the packed Versions but they should work in other than Debian based Distributions.
73 de Heinz-Juergen
 

DO1YHJ
A quick check with a Editor

A quick check with a Editor shows a lot of Callsigns. Looks like Members of LOTW, not entries compared to the log. I don't use LOTW.

oh1kh
Re: wondering if waiting might be smart?

Hi Petr!

> I just released new version, it should fix the bug

Does this mean that DXCC updates are not fixed, but program is instead?
I.E. DXCC updates do not fit to 1.9.0 any more :(

--
Saku
OH1KH

ok2cqr
ok2cqr's picture
Re: Re: wondering if waiting might be smart?

Hi Saku,
 
I'm sorry, it won't be compotible with all previous version of CQRLOG because of bug in CQRLOG. It's really easy to fix, look at the commits:
https://github.com/ok2cqr/cqrlog/commit/217378de592b593bba3e7eff4af84faf...
and
https://github.com/ok2cqr/cqrlog/commit/de23ffa93be8a5021a9ef1b027745313...
 
The code is good cadidate to refactoring and I'll work on it.
 
73 Petr