Could be a buffer flushing problem on the segfault.
Here's more context
[20190124 06:32:14.097 Eastern Standard Time D]
C:\JTSDK-Tools\tmp\wsjtx\HamlibTransceiver.cpp:1017 -
"HamlibTransceiver::poll:" rig_get_ptt PTT = 0[20190124 06:32:15.061 Eastern
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:764 -
Configuration::transceiver_online: Transceiver::TransceiverState(online: yes
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(DIG_U); SPLIT: on; PTT:
off)[20190124 06:32:15.061 Eastern Standard Time D]
C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:787 -
Configuration::transceiver_frequency: 7074000
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 7073500Hz}
Transceiver::MODE(DIG_U); SPLIT: on; PTT: off)[20190124 06:32:15.061 Eastern
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:795 -
Configuration::transceiver_tx_frequency: 7073500
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 7073500Hz}
Transceiver::MODE(UNK); SPLIT: on; PTT: off)[20190124 06:32:15.061 Eastern
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\EmulateSplitTransceiver.cpp:23 -
EmulateSplitTransceiver::set: state: Transceiver::TransceiverState(online: yes
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(UNK); SPLIT: on; PTT: off)
#: 1698[20190124 06:32:15.061 Eastern Standard Time D]
C:\JTSDK-Tools\tmp\wsjtx\Configuration.cpp:813 -
Configuration::transceiver_ptt: true Transceiver::TransceiverState(online: yes
Frequency {7074000Hz, 7073500Hz} Transceiver::MODE(UNK); SPLIT: on; PTT:
off)[20190124 06:32:15.061 Eastern Standard Time D]
C:\JTSDK-Tools\tmp\wsjtx\TransceiverBase.cpp:44 - "TransceiverBase::set:" #:
1698 Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 0Hz}
Transceiver::MODE(UNK); SPLIT: off; PTT: off)[20190124 06:32:15.061 Eastern
Standard Time D] C:\JTSDK-Tools\tmp\wsjtx\EmulateSplitTransceiver.cpp:41 -
EmulateSplitTransceiver::handle_update: from wrapped:
Transceiver::TransceiverState(online: yes Frequency {7074000Hz, 0Hz}
Transceiver::MODE(DIG_U); SPLIT: off; PTT: off)
On Thursday, January 24, 2019, 4:05:37 PM CST, Bill Somerville
<g4...@classdesign.com> wrote:
On 24/01/2019 21:07, Black Michael via wsjt-devel wrote:
If appears to me that the new_state variable is passed by reference to the
update event and it may be losing scope before being handled.
Hi Mike,
I doubt that. The signal is not crossing a thread boundary so it will simply be
a function call. If it did cross a thread boundary then the object is
serialized so is effectively passed by value. Either way the scope of the
object should be fine.
If you want to be certain you can simply change the signal definition in
Transceiver.hpp to take that argument by value for a test, no other code will
need changing as it is equivalent.
// rig state changed
Q_SIGNAL void update (Transceiver::TransceiverState,
unsigned sequence_number) const;
Debug trace lines missing when there is a program crash is likely to be a
buffer flushing issue, is it a crash you are trying to debug?
Are you sure your analysis is correct, the trace message you show above is
coming from the Transceiver instance used for PTT wrapped one used for rig
control, that setup is due to RTS or DTR on a second serial port being selected
for PTT. That seems an unlikely setup for a Flex Radio SDR.
73
Bill
G4WJS.
_______________________________________________
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
