Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [ntp:questions] Ntpd in uninterruptible sleep?



On Thu, Nov 17, 2011 at 15:10, Martin Husemann
<martin%homeworld.netbsd.org@localhost> wrote:
> On Thu, Nov 17, 2011 at 08:56:00AM +0000, Dave Hart wrote:
>> Evidence has changed, and now I do believe it's a bug in sparc32
>> dtoa().  This should be relatively easy to confirm with a test program
>> that beats on dtoa().
>>
>> See:
>>
>> http://lists.ntp.org/pipermail/questions/2011-November/030984.html
>
> Can one of you please provide the testes "snprintf hack" as diff?
> I don't see what invocation in ntpd is actually triggering the problem.
>
> The -current dtoa code is pretty stock stuff, only sparc speciality is
> the endianess. It should be reproducable on other archs as well, so we
> realy need a good test case.

The snprintf workaround was simply to build recent ntpd 4.2.7 using
configure option --enable-c99-snprintf, which forces the use of
C99-snprintf [1] instead of the C runtime's snprintf.  Note
C99-snprintf() hand-rolls its dtoa()-like functionality.  This message
shows the stack backtrace AGC saw repeatedly when he broke into an
infinitely-looping ntpd that triggered it, and the ntpd code in
question, which amounts to snprintf(bufwif, plentyspace, " %.2f",
dblX); where apparently there are certain double values that trigger
it.  As I mentioned elsewhere, this should be reproducible feeding
random doubles to dtoa(), or at least feeding such to a similar
snprintf().

[1] http://www.jhweiss.de/software/snprintf.html

Hope this helps,
Dave Hart


Home | Main Index | Thread Index | Old Index