On 2/7/2012 19:12, Dave Hart wrote:
On Tue, Feb 7, 2012 at 18:46, Dave Hart<[email protected]> wrote:
On Tue, Feb 7, 2012 at 18:38, A C<[email protected]> wrote:
On 2/7/2012 10:21, Dave Hart wrote:
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.
No idea. However, you don't have to wait for it to hang to see if the
option is working as intended. After building, look in the build tree
for config.h and grep it for rpl_snprintf. You should see #define
snprintf rpl_snprintf, otherwise it didn't take. If it didn't, email
me the config.log.
It appears to be a bug in code I added to sntp/m4/snprintf.m4 (from
the C99-snprintf package, but not yet integrated upstream). See
http://bugs.ntp.org/2134 for details. Thanks the agcarver for quickly
helping identify it, and here's hoping it's the reason his NetBSD
5.1/sparc ntpd has been going haywire with its known-bad dtoa() used
by its libc *snprintf routines.
The latest version is now compiled and running. I'll let it go and see
what happens over the next week. Just as a point of reference, the
system has been without ntpd (or any other clock discipline) for about
three days and the clock was only off by about 1 millisecond when I
started ntpd up again. So it would appear that the system oscillator is
reasonably stable and I don't have to be as concerned that it's doing
something strange to cause the multi-second jumps.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
