On Feb 20, 11:02 am, Harlan Stenn <[EMAIL PROTECTED]> wrote: > Well, the good news is the problem is now obvious. > > We know it is from the call to abort() at line 788 of refclock_true.c.
Yep. Unfortunately, the code should never get there. Yea, right. > > Please open an issue ahttp://bugs.ntp.isc.orgwith this information. > > The bad news is that refclock_true.c does not have a maintainer - anybody > want to volunteer? > > H Its probably necessary to own one of the beasts that this code was designed to handle in order to do anything with it. The likelihood that many folks with programming skills have one any more is slim, so its unlikely you will find a volunteer. Please don't mark me as "maintainer", but I will spend some time on solving this. It appears that the state machine gets severely confused. I have confirmed that the first string returned to the driver is actually a valid truetime timecode which certainly shouldn't cause a call to abort. The abort call is the default action at the end of a switch/case block where the value of the switch must contain something not recognized. Now to find it.:) I suspect I'll be putting lots of debug print statements in the code. Wish me luck. Roger _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
