On Wed, Mar 7, 2012 at 12:08, Christos Zoulas<christos%zoulas.com@localhost>
wrote:
On Mar 7, 12:08am, agcarver+netbsd%acarver.net@localhost (AGC) wrote:
-- Subject: Re: ntpd wedged by libc?
| I ran the test with both %.6f and stepped it up even further all the way
| to %.10f with no ill effects. The test passed all the extra precision
| formats:
Comment out the sprintf in ntpd or replace it with something else and see
if it survives...
I'm pretty sure it will. Before the libc repair, AGC found he could
work around the problem by configuring ntpd 4.2.7 with
--enable-C99-snprintf, which forces use of a handrolled
printf/snprintf/vsnprintf replacement package otherwise used only if
the default snprintf is not C99-compliant. That implementation does
not use dtoa() and he found ntpd survived indefinitely.
The key difference between ntpd's use of snprintf and t_printf.c may
be simply the number of calls over time from the same process. AGC is
polling ntpd every 5 seconds with ntpq -p, which triggers about 7
floating point snprintf()s per peer (line of the ntpq -p peers
billboard table). I believe all of those are using "%.3f".
You might be able to expose the bug with t_printf.c by changing it to
generate and snprintf thousands of random floating point numbers.
AGC, approximately how long does it take for ntpd to get wedged with
the latest libc? And how many peers are there in your ntpq -p output?