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

[Dave Hart <hart%ntp.org@localhost>]

On Thu, Nov 17, 2011 at 15:51, Martin Husemann <martin%duskware.de@localhost> 
wrote:
> On Thu, Nov 17, 2011 at 04:34:32PM +0100, Martin Husemann wrote:
>> On Thu, Nov 17, 2011 at 03:24:44PM +0000, Dave Hart wrote:
>> > Er, sorry, this message:
>> >
>> > http://lists.ntp.org/pipermail/questions/2011-November/030930.html
>>
>> Hmm, a failure of snprintf to honor the length limit (or something like
>> that) would also be able to exceed the buffer and cause an infinite
>> loop, or am I reading the code wrong?
>
> Actually, I see the NTP_INSIST() that should notice such a case - is it
> always enabled or maybe compiled out of the version AGC is using?

NTP_INSIST() always generates code, even if you build without DEBUG
(using configure option --disable-debugging).

> I wrote a test program and see pretty long strings come out of the
> snprintf:
>
> random bits: 7530f16f519ecc4e
> as double: 
>  31800161180630135324850650778062798989665665794445179024977745204547212139766087116454345238785827763116457201339666930246252988215613431084922037173985266379603142447030361959225451187759570621037814117956671720979721413044097623357923659793294040554799104.00

Impressive.  Was this with "%.2f"?

> random bits: 3c69e3053a40ce7c
> as double:  0.00
>
> random bits: 4105358b571f5f5a
> as double:  173745.42
>
> random bits: 592aaa817a0a5668
> as double: 
>  34429186891229910846439240242941960408419130789446515545921377202903150945262572287928769623119711035587926424428547670016.00
>
> random bits: 388f9f6717e41726
> as double:  0.00
> ...
>
> But I haven't found anything that goes into an endless loop yet.

For ntpd, the numbers aren't random, of course.  Here's what the
output typically looks like:

hart@psp-fb2> ntpq -c raw -c 'rv &2'
Output set to raw
associd=14805 status=0x763a,
srcadr=149.20.68.29, srcport=123, dstadr=224.0.123.123, dstport=123,
leap=0, stratum=14, precision=-20, rootdelay=1.999, rootdisp=264.206,
refid=149.20.68.28, reftime=0xd26fbdd6.b3088e0d,
rec=0xd26fbde4.385c95d2, reach=0x7e, unreach=0, hmode=6, pmode=5,
hpoll=6, ppoll=6, headway=0, flash=0x0, keyid=123, offset=-0.062,
delay=0.227, dispersion=0.949, jitter=0.033, xleave=0.074,
filtdelay= 0.23 0.23 0.23 0.23 0.23 0.37 0.23 0.26,
filtoffset= -0.06 -0.06 -0.07 -0.08 -0.08 -0.01 -0.01 -0.01,
filtdisp= 0.00 0.96 1.95 2.94 3.95 4.91 5.81 5.84

The last three lines are the ones from ctl_putarray().

Thanks for digging into this.  Your test program is close what I had
it mind.  I was thinking output only the hex values followed by \r to
avoid scrolling the terminal for speed, expecting when it went into an
infinite loop, the interesting hex value would be visible.  AGC, what
does your ntpq show if you try similar commands, varying from &1 to
the number of associations?  'rv &X' happens under the hood for each
line of ntpq -p, and -c raw shows the text as it is on the wire (at
least for these filt*=).

Cheers,
Dave Hart