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

[wa6zvp]

On Feb 22, 10:05 am, Ronan Flood <use... at umbral.org.uk> wrote:
> "wa6zvp" <wa6... at gmail.com> wrote:
> > > matching cases in the switch.  What was the value of up->type when
> > > it got to line 788?  And up->state?
>
> > * My recollection is that up->type actually had t_unknown in it,
> > making it even more puzzling.  Don't remember state.

** Yes. I remembered correctly. up-type = t_unknown, up->state =
s_Base, and event = e_Poll.
 Very bizarre.  See below.

> Hmm, I'm wondering if the fact that there's no "break" after the
> call to msyslog at line 784 could be significant?  Surely not.

* Don't think so.

> > If I start ntpd with gdb, it just says 'normal completion', meanwhile
> > the forked process crashes.  Is there a way to get gdb to follow into
> > the forked process?  If not, I have to get it running without the data
> > and attach to the running process. This will have to wait till tonight.
>
> The -n option to ntpd will keep it in the foreground, not sure how
> you pass that to it from gdb, um
>
>  gdb ntpd
>  run -n
>
> maybe?

**
gdb ntpd
(gdb) set args -n
      run

* Despite the fact that doevent is entered with valid params for type
and state,
that is, t_unknown and t_Base, it still gets to the abort statement at
the end
of the function whenever its called with event = e_Poll.

Nowhere in this function is this event handled or used.  Not even
mentioned.

So, I backed out my hack from last night, and now have
simply commented out the one and only line that calls
doevent with event=e_Poll.  Line 540 in function true_receive.

Thanks, Ronan, for giving me the encouragement to at least learn
a little bit about gdb.

Maybe if gdb can do a conditional break, and stop at the top of
doevent
if event=e_Poll.  Then I could try stepping it and see what happens.
Or not.:)

   Roger