[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ntpd wedged by libc?
On Mar 7, 5:14pm, hart%ntp.org@localhost (Dave Hart) wrote:
-- Subject: Re: ntpd wedged by libc?
| On Wed, Mar 7, 2012 at 12:08, Christos Zoulas <christos%zoulas.com@localhost>
| > 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 wa=
| > | to %.10f with no ill effects. =A0The test passed all the extra precisio=
| > | 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.
That is what t_printf does... One million snprintf random numbers. Another
thing to do is to run top while it is running to see if it grows...
Main Index |
Thread Index |