[ntp:questions] refclock use causes core dump of ntpd
wa6zvp at gmail.com
Thu Feb 22 04:57:56 UTC 2007
On Feb 20, 10:51 pm, "wa6zvp" <wa6... at gmail.com> wrote:
> On Feb 20, 11:02 am, Harlan Stenn <s... at ntp.isc.org> 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.
OK, I got warm and cuddly with gdb, at least enough to set some
and look at variables.
The main culprit looks like line 540 (in refclock_true). This is in
received data function. It calls true_doevent with a parameter of
Event e_Poll is never handled anywhere in doevent, so is very state
Even replacing line 788, the original abort call location with a
the program would abort at other unhandled places in doevent.
I suppose its possible that all the 'intended' refclocks for this
behaved in a way that this issue never cropped up. But this is the
driver for the clock I have, since it has the exact timestamp parsing
Knowing I'm probably the only person in the world trying to attach
clock to NTP, there is not much reward in spending hours and hours to
incorporate the clock specific things necessary into the code. So I
took a different route. I added 'break' statements before each
statement in this driver. It now performs quite nicely, thank you.
Here is the end result:
lunar# ntpq -p
remote refid st t when poll reach delay
*TRUETIME(0) .WWV. 0 l 34 64 377 0.000
+SPECTRACOM(0) .WWVB. 0 l 36 64 377 0.000
-Remote 1 .GPS. 1 u 94 256 377 24.973
+Remote 2 .WWV. 1 u 98 256 377 23.715
-Remote 3 .GPS. 1 u 35 512 377 24.024
Note that the WWVB rx is not performing well at this moment. This is
time of the day (first few hours after sunset) for 60Khz propagation
to my QTH.
It will settle right in with the others in another hour or two.
Thanks Harlan for your suggestions.
More information about the questions