On 11/12/2011 00:01, Dave Hart wrote:
On Sat, Nov 12, 2011 at 03:19, Dave Hart<h...@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-sp...@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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
