[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ntpd wedged by libc?
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
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()...
Main Index |
Thread Index |