> BTW please cc: [EMAIL PROTECTED] so that this discussion is on record.
Oh, sorry, I thought that was a bad idea after the bug was closed.
The ridiculously high values come from the line
sources = MallocArray(struct SRC_Instance_Record *, max_n_sources);
in SRC_CreateNewInstance in sources.c.
I put a watchpoint on
sources[0]->stats.offset_time.tv_sec
with condition '> 0xffffffff'.
It never triggered when at the calltree
main () at main.c:304
SCH_MainLoop () at sched.c:470
read_from_socket () at ntp_io.c:215
NSR_ProcessReceive () at ntp_sources.c:258
receive_packet () at ntp_core.c:1063
SRC_SelectSource () sources.c:693
REF_SetReference () at reference.c:408
LCL_AccumulateOffset () at local.c:446
slew_sources () at sources.c:761
sources is defined static in this file.
SST_SlewSamples () at sourcestats.c:698
parameter inst = sources[1]->stats in caller
UTI_DiffTimevalsToDouble () at util.c:161
parameter b = inst->offset_time of caller
the value was, for the first time, used to calculate the result of
UTI_DiffTimevalsToDouble (line numbers apply to 1.23-2 sources plus the
instrumentation patches I sent you off-list).
This missing initialization was obviously harmless in the 32-bit version, but
you should ask upstream for the implications of a huge random starting value.
It might be that with your divider/remainder patch the program won't loop till
the sun goes out, but nontheless take an eternity until the system time
converges to UTC.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
