[ntp:questions] ntpd wedged again
hart at ntp.org
Wed Feb 8 03:12:14 UTC 2012
On Tue, Feb 7, 2012 at 18:46, Dave Hart <hart at ntp.org> wrote:
> On Tue, Feb 7, 2012 at 18:38, A C <agcarver+ntp at acarver.net> 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.
More information about the questions