[ntp:questions] refclock use causes core dump of ntpd
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
> 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.
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