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

Ronan Flood usenet at umbral.org.uk
Thu Feb 22 15:04:38 UTC 2007


"wa6zvp" <wa6zvp at gmail.com> wrote:

> > > 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.

That's more understandable, but looking at the code I don't see how it
got to line 788, since that's the default on a switch(up->type) which
should only ever be one of t_unknown, t_goes, t_omega, t_tm, or t_tcu
as they are the only values ever assigned to it, and they all have
matching cases in the switch.  What was the value of up->type when
it got to line 788?  And up->state?

What I'd expect is that the state machine starts with t_unknown and
s_Base then sees e_Init, from true_start() lines 290-292, which takes
it into ss_InqGOES.  If it then gets e_Poll from true_receive(), it
would abort at line 726.  Various other scenarios I have not looked
at exhaustively, but getting to line 788 is puzzling ...

-- 
Ronan Flood <usenet at umbral.org.uk>




More information about the questions mailing list