Re: ntpd wedged by libc?

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

On 7 March 2012 22:29, AGC <agcarver+netbsd%acarver.net@localhost> wrote:
> On 3/7/2012 13:57, Dave Hart wrote:
>
> Yes, when it wedges it uses upwards of 80-90% CPU according to top but is
> otherwise unresponsive unless issued a SIGKILL, SIGTERM, or SIGHUP. I attach
> gdb to it while it's spinning the CPU that's where I get the stack trace.
>  Interestingly a simple SIGTERM will break the loop and ntpd will actually
> close out normally -- it issues the exit messages in the logs about
> releasing kernel discipline and then message "exit on signal 15" (or
> whatever the number is for a kill command with no signal flag, I don't
> recall).

Apologies if I've misunderstood something here, but if using the hand
rolled snprintf does not use dtoa() and avoids the issue would it make
sense to try one of:

a) Modify the hand rolled snprintf to use dtoa() to confirm it is the
dtoa() calls, plus have it keep a static fd open and just write out
the argument before calling each dtoa(). If it hangs, you have a
history of dtoa() calls which you can replay in a test app to see
which bit pattern or sequence of bit patterns causes the issue.

b) Like a) but add the logging to the system snprint() and compiling a
custom libc.so which is referenced by LD_LIBRARY_PATH

c) If the dtoa() log is unhelpful, similar but logging the stdarg
values to snprintf()...