[ntp:questions] refclock use causes core dump of ntpd
wa6zvp at gmail.com
Fri Feb 23 04:01:38 UTC 2007
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
(gdb) set args -n
* Despite the fact that doevent is entered with valid params for type
that is, t_unknown and t_Base, it still gets to the abort statement at
of the function whenever its called with event = e_Poll.
Nowhere in this function is this event handled or used. Not even
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
if event=e_Poll. Then I could try stepping it and see what happens.
More information about the questions