Re: ntpd wedged by libc?

[David Brownlee <abs%netbsd.org@localhost>]

On 7 February 2012 23:13, AGC <agcarver+netbsd%acarver.net@localhost> wrote:
> On 2/7/2012 13:43, David Laight wrote:
>>
>> On Tue, Feb 07, 2012 at 09:40:46AM -0800, AGC wrote:
>>>
>>> Seems I'm still having issues with libc on 5.1/sparc specifically with
>>> ntpd wedging when doing math:
>>>
>>> #0  0x103d38c8 in __pow5mult_D2A () from /usr/lib/libc.so.12
>>> #1  0x103d3ac4 in __muldi3 () from /usr/lib/libc.so.12
>>> #2  0x103d34dc in __mult_D2A () from /usr/lib/libc.so.12
>>> #3  0x103d3728 in __pow5mult_D2A () from /usr/lib/libc.so.12
>>> #4  0x103c61d4 in __dtoa () from /usr/lib/libc.so.12
>>> #5  0x103c315c in __vfprintf_unlocked () from /usr/lib/libc.so.12
>>> #6  0x103330c4 in snprintf () from /usr/lib/libc.so.12
>>> #7  0x000256f4 in ctl_putdblf (tag=0x87d79 "", fmt=0x88458 "%.3f",
>>> d=4.5623779296875)
>>>     at ntp_control.c:1431
>>> #8  0x00025ed0 in ctl_putpeer (id=14, p=0xb1bc0) at ntp_control.c:2459
>>> #9  0x0002adbc in read_variables (rbufp=0x10522000, restrict_mask=0) at
>>> ntp_control.c:2981
>>> #10 0x00028798 in process_control (rbufp=0x10522000, restrict_mask=0) at
>>> ntp_control.c:1121
>>> #11 0x00038150 in receive (rbufp=0x10522000) at ntp_proto.c:417
>>> #12 0x0002323c in ntpdmain (argc=0, argv=0xefffe8a8) at ntpd.c:1069
>>> #13 0x000138bc in ___start ()
>>> #14 0x000137f4 in _start ()
>>>
>>>
>>> Ideas anyone?
>>
>>
>> Wasn't there some silly fubar bug in dtoa() ??
>>
>>        David
>>
>
> Yes, it's there somehow but it's apparently in libc.  I had compiled a
> workaround inside ntpd which appears to be working, I'm doing more tests.

Apologies for asking a potentially stupid question:

Assuming this is just a specific toxic value or values, rather than
some strange state caused by a sequence of events, is it not possible
to run with a version of libc which logs every value passed to dtoa(),
or just run a (quite long running :) test program which tests every
bit pattern?