[ntp:questions] refclock use causes core dump of ntpd

wa6zvp 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
breakpoints
and look at variables.

The main culprit looks like line 540 (in refclock_true).  This is in
the
received data function.  It calls true_doevent with a parameter of
e_Poll.
Event e_Poll is never handled anywhere in doevent, so is very state
dependant.

Even replacing line 788, the original abort call location with a
break;,
the program would abort at other unhandled places in doevent.

I suppose its possible that all the 'intended' refclocks for this
driver
behaved in a way that this issue never cropped up.  But this is the
logical
driver for the clock I have, since it has the exact timestamp parsing
needed.

Knowing I'm probably the only person in the world trying to attach
this
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
'abort'
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
offset  jitter
==============================================================================
*TRUETIME(0)     .WWV.            0 l   34   64  377    0.000
2.586   1.311
+SPECTRACOM(0)   .WWVB.           0 l   36   64  377    0.000
-19.930   8.259
-Remote 1        .GPS.            1 u   94  256  377   24.973
2.271   1.014
+Remote 2        .WWV.            1 u   98  256  377   23.715
1.790   2.170
-Remote 3        .GPS.            1 u   35  512  377   24.024
2.364   2.465

Note that the WWVB rx is not performing well at this moment.  This is
the worst
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.

     Roger




More information about the questions mailing list