On 2/7/2012 10:21, Dave Hart wrote:
On Tue, Feb 7, 2012 at 17:37, A C<[email protected]> wrote:
It appears that ntpd is wedged again in libc. I'm not sure (but it's
likely) if this is the source of the random behavior lately with ntpd
spinning offsets out of control but I've ruled out the GPS by noselecting
the PPS signal, turning off kernel PPS and monitored the PPS signal
externally. There were no missing pulses or drastic phase shifts but ntpd
spun out of control oscillating throug multisecond offsets across all
sources.
Right now ntpd is using 80% CPU but not responding to anything. This copy
is compiled with the C99 flag (from a previous thread with the broken dtoa
issue).
Looks like I'll have to take this over to NetBSD's list for now.
#0 0x103d38c8 in __pow5mult_D2A () from /usr/lib/libc.so.12
#1 0x103d3ac4 in __muldi3 () from /usr/lib/libc.so.12
#2 0x103d34dc in __mult_D2A () from /usr/lib/libc.so.12
#3 0x103d3728 in __pow5mult_D2A () from /usr/lib/libc.so.12
#4 0x103c61d4 in __dtoa () from /usr/lib/libc.so.12
#5 0x103c315c in __vfprintf_unlocked () from /usr/lib/libc.so.12
#6 0x103330c4 in snprintf () from /usr/lib/libc.so.12
#7 0x000256f4 in ctl_putdblf (tag=0x87d79 "", fmt=0x88458 "%.3f",
d=4.5623779296875)
at ntp_control.c:1431
Thanks for the heads-up. Assuming by "the C99 flag" you mean it was
configured using --enable-c99-snprintf, that flag didn't "take". If
it had, you wouldn't be using libc's snprintf, you'd be using libntp's
rpl_snprintf() which would have called rpl_vsnprintf(), and based on
previous experience, it wouldn't have resulted in an infinite loop.
I was wondering about that. I recompiled it twice with that configure
option. Any idea why it would have been ignored this time? I'll
rebuild it and see what happens.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
