Re: ntpd wedged by libc?

[christos%zoulas.com@localhost (Christos Zoulas)]

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> 
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 wa=
| y
| > | to %.10f with no ill effects. =A0The test passed all the extra precisio=
| n
| > | 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...

christos