Re: ntpd wedged by libc?

[AGC <agcarver+netbsd%acarver.net@localhost>]

On 4/2/2012 12:59, Christos Zoulas wrote:
> On Apr 2, 12:29pm, agcarver+netbsd%acarver.net@localhost (AGC) wrote:
> -- Subject: Re: ntpd wedged by libc?
>
> | I tried something when ntpd got hung today.  I used the debugger to
> | forcibly end the stuck call:
>
> Ok, hung, but not spinning? Is it taking a lot of CPU or not?

Yes, it is spinning at 80-90% CPU.

> | This seems to have gotten it unstuck because ntpd started running
> | normally again as soon as I exited gdb.
> |
> | It was in the middle of writing to a file when the code bombed.  The
> | area around the log file was (not that I think it's terribly useful):
> |
> | 56019 40827.814  0.000070325 -77.589  0.000122070  0.001219 4
> | 56019 40843.823  0.\x00\x00\x00 -77.587  0.000122070  0.001200 4
> | 56019 50415.027  0.000000000 -77.587  0.000122070  0.001123 6
> |
> |
> | So it appears there's an infinite loop occurring in __mult_D2A (or
> | possibly above it in _pow5mult_D2A)
>
> One of the things you can try to do is to comment out the ACQUIRE/FREE
> lock calls with a (1) argument. This can waste a bit more memory, but
> will avoid deadlocks or long waits in the pow5mult computation.

I can give that a try later this week.