[ntp:questions] Ntpd in uninterruptible sleep?

A C agcarver+ntp at acarver.net
Sat Nov 12 08:08:14 UTC 2011


On 11/12/2011 00:01, Dave Hart wrote:
> On Sat, Nov 12, 2011 at 03:19, Dave Hart<hart at ntp.org>  wrote:
>> Excellent.  I assume the stack trace is from ntpd 4.2.6p3.  I think
>> you've found a bug in your system's libc dtoa() exposed by its
>> snprintf(s, " %.2f", ...).  I believe you will not be able to
>> reproduce the bug using 4.2.7, as that version of ntpd uses
>> C99-snprintf [1] if the system snprintf() is not C99-compliant.
>> C99-snprintf's rpl_vsnprintf() does not use dtoa(), it hand-rolls the
>> double-to-ascii conversion.  Below is the code in ntpd.  NTP_SHIFT is
>> 8.  I claim the ntpd code is correct and your system's dtoa() and
>> thereby snprintf() of double (floating point) is subject to infinite
>> looping for some values.
>
> I was confused.  Thinking of the antique hardware involved, I was
> assuming wrongly that the system-provided snprintf() was not
> C99-compliant.  In fact, the antique is running modern NetBSD 5.x,
> which undoubtedly does provide a C99 snprintf().
>
> But wait, there's more.  I was also probably wrong in saying that this
> is a bug in 32-bit SPARC NetBSD 5.x dtoa().  That code is likely quite
> mature and such a bug would have been found before now.  My hunch is a
> hardware bug, but I'll pursue that on the port-sparc at netbsd.org list.
> I will report back here once it's resolved, if Mr. Carver does not.
>

I'll gladly report back to the list if the bug is discovered wherever it 
might reside.  However, if there's a hardware bug affecting dtoa() then 
it should manifest in the gpsd code that is also running on the system 
and also using snprintf().  The first question is to determine the 
conditions that cause a runaway dtoa() since it seems to only affect one 
program and not the other.


More information about the questions mailing list