After more study of the code, I might have been wrong but there might another beginning of a scenario explaining why fldigi sometimes freezes with jPSKMail:
Is it possible that fldigi receives a string containing a substring similar to:
"<mode>PTTTUNExxxx</mode>" where xxxx would be an integer ? Or rather, an INVALID integer ????
And has anyone the slightest idea why ParseMode() calls push2talk->set in the thread dedicated to FLTK display ?
Thanks R Le 22.03.2012 23:15, remi.chateauneu@xxxxxxxxx a écrit :
Hi All,
I try to chase a possible bug which might be related to the activation
of the PTT in the context of the ARQ server, and I saw this:
$ grep push2talk src/*/*cxx | grep -w set
src/misc/arq_io.cxx:
REQ_SYNC(&PTT::set, push2talk, true);
REQ_SYNC(&PTT::set, push2talk, false);
src/trx/trx.cxx:
push2talk->set(true);
push2talk->set(false);
push2talk->set(true);
push2talk->set(false);
This means that the function PTT::set can be called in two different
threads:
- Transmit thread: functions trx_trx_transmit_loop and trx_tune_loop
- ARQ thread, function ParseMode
The function PTT::set calls hamlib_set_ptt which works basically this way:
void hamlib_set_ptt(int ptt)
{
LockMutex
setPtt
IfErrorThenLeavesPttWithoutUnlocking
UnlockingMutex
}
A possible error is that:
* If Hamlib had a problem setting the PTT then it will leave without
unlocking the mutex.
* If later on, a thread tries to set the PTT, it will just hang, waiting
for the mutex to be unlocked.
So I have two questions:
* Could you please confirm than when the problem happens, one thread is
frozen ?
* Is it possible that for any reason, the PTT did not work, just once ?
* Did someone saw in the logfile a message containing the string: "Rig
PTT" ?
Many thanks for any information.
Whatever the answer is, I think this can be considered as a therotical
bug at least, so I will suggest a fix.
If someone is interested, a good way to prove this is to trigger a ptt
problem (Unplugging the cable ? Manually setting the PTT ?)
Sincerely hope it helps.
R
