On Tue, Feb 7, 2012 at 17:37, A C <agcarver+...@acarver.net> 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. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions