Date
1 - 10 of 10
Locked 2.5.0 RC6 issue #Linux and K3 #linux #Elecraft
|
Bill Carpenter
I have found that if I try to use "rig" for split operation that WSJT 2.5.0 - RC6 will totally disappear when I click on the frequency up/down arrows and I have to re-start it. This does not happen if I use "fake it". I did not see this happen with RC5. It's not a problem because split works fine in "fake it" but thought it was worth bringing up here. I'm using Mint 20.2 Mate. Maybe it's related to the K3 timing issue?
No problem with split using my IC-7610. 73, Bill NZ0T |
|
|
|
On 21/09/2021 01:54, Bill Carpenter wrote:
I have found that if I try to use "rig" for split operation that WSJT 2.5.0 - RC6 will totally disappear when I click on the frequency up/down arrows and I have to re-start it. This does not happen if I use "fake it". I did not see this happen with RC5. It's not a problem because split works fine in "fake it" but thought it was worth bringing up here. I'm using Mint 20.2 Mate. Maybe it's related to the K3 timing issue?Hi Bill, which frequency up/down arrows are you referring to? 73 Bill G4WJS. |
|
|
|
Bill Carpenter
The arrows that move the TX and RX brackets on the waterfall.
|
|
|
|
On 21/09/2021 22:28, Bill Carpenter wrote:
The arrows that move the TX and RX brackets on the waterfall.Hi Bill, I assume this happens when the Tx audio offset crosses a 500 Hz boundary. Can you confirm that please? I see no way that moving the Rx audio offset can have any relationship with CAT settings, can you reconfirm that moving the Rx audio offset can cause this issue please? 73 Bill G4WJS. |
|
|
|
Bill Carpenter
Biull,
It happens when I click the arrow to "Set TX frequency to RX frequency". It does not happen when I click the opposite arrow. The waterfall stops moving and then the program shuts down. This is only in "rig" split, it doesn't happen in "fake it". It only happens with my K3, my IC-7610 works fine in "rig". split. 73, Bill NZ0T |
|
|
|
On 22/09/2021 13:26, Bill Carpenter
wrote:
Biull, Hi Bill, OK, so set the Rx offset to 1200 Hz and the Tx offset to 1300 Hz, then click the copy Rx offset to Tx offset arrow. Please confirm that does not cause the issue? If that is the case, then install gdb: sudo apt install gdb put the attached file in your WSJT-X configuration files directory (~/.config/ on Linux), run wsjtx under the control of gdb from a terminal: gdb `which wsjtx` start the application by typing 'run' and ENTER at the (gdb)
prompt, set the Rx offset at least 500 Hz below or above the Tx
offset, then click the copy Rx offset to Tx offset arrow. If the
program crashes it should return to the (gdb) prompt with a note
of the signal that caused the crash. Type 'bt' and ENTER at the
(gdb) prompt, then report back what is printed to the terminal
please? You can quit gdb by typing 'quit' and ENTER at the (gdb)
prompt. There should also a file on your Desktop called WSJT-X_RigControl.log , send me (g4wjs <at> classdesign <dot> com) that file for analysis please? Once the test is complete and you have sent me the WSJT-X_RigControl.log file you can revert to normal operation by deleting the log configuration file and log file before restarting WSJT-X: rm ~/config/wsjtx_log_config.ini ~/Desktop/WSJT-X_RigControl.log You can also uninstall gdb if you wish. 73 |
|
|
|
Bill Carpenter
Hi Bill,
I hope I did this correctly! Here si what was reported after bt: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff5d73859 in __GI_abort () at abort.c:79
#2 0x00007ffff5dde3ee in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x7ffff5f0807c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007ffff5e80b4a in __GI___fortify_fail
(msg=msg@entry=0x7ffff5f08012 "buffer overflow detected")
at fortify_fail.c:26
#4 0x00007ffff5e7f3e6 in __GI___chk_fail () at chk_fail.c:28
#5 0x00007ffff5e7ec7a in __strcat_chk
(dest=<optimized out>, src=<optimized out>, destlen=<optimized out>)
at strcat_chk.c:34
#6 0x000055555594bf03 in ()
#7 0x00005555558bf1ab in ()
#8 0x00005555558c2e37 in ()
#9 0x00005555558322a2 in ()
#10 0x00005555558add19 in ()
#11 0x00007ffff66fbd5a in QObject::event(QEvent*) ()
at /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007ffff740da66 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007ffff74170f0 in QApplication::notify(QObject*, QEvent*) ()
at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
--Type <RET> for more, q to quit, c to continue without paging--
I sent the log to you via email. 73, Bill NZ0T |
|
|
|
Mike Black
If the last thing in the log is set_vfo then this bug has been fixed and will be in the final WSJTX release. Mike W9MDB
On Wednesday, September 22, 2021, 04:24:35 PM CDT, Bill Carpenter <nz0tham@...> wrote:
Hi Bill, I hope I did this correctly! Here si what was reported after bt: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff5d73859 in __GI_abort () at abort.c:79
#2 0x00007ffff5dde3ee in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x7ffff5f0807c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007ffff5e80b4a in __GI___fortify_fail
(msg=msg@entry=0x7ffff5f08012 "buffer overflow detected")
at fortify_fail.c:26
#4 0x00007ffff5e7f3e6 in __GI___chk_fail () at chk_fail.c:28
#5 0x00007ffff5e7ec7a in __strcat_chk
(dest=<optimized out>, src=<optimized out>, destlen=<optimized out>)
at strcat_chk.c:34
#6 0x000055555594bf03 in ()
#7 0x00005555558bf1ab in ()
#8 0x00005555558c2e37 in ()
#9 0x00005555558322a2 in ()
#10 0x00005555558add19 in ()
#11 0x00007ffff66fbd5a in QObject::event(QEvent*) ()
at /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007ffff740da66 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007ffff74170f0 in QApplication::notify(QObject*, QEvent*) ()
at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
--Type <RET> for more, q to quit, c to continue without paging-- I sent the log to you via email. 73, Bill NZ0T |
|
|
|
Hi Mike,
probably not that as it doesn't look
like the crash is in the rig control thread. Unfortunately I need
the thread info or the full backtrace to be sure. I'll report back
when I have the trace log from Bill.
73
Bill G4WJS. On 22/09/2021 22:37, Michael Black via
groups.io wrote:
|
|
|
|
Bill Carpenter
I loaded v2.5.0 and the problem is no longer an issue.
Thanks to all of you! 73, Bill NZ0T |
|
|