"wa6zvp" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
