Re: ntpd wedged by libc?

[christos%zoulas.com@localhost (Christos Zoulas)]

On Apr 2,  1:01pm, agcarver+netbsd%acarver.net@localhost (AGC) wrote:
-- Subject: Re: ntpd wedged by libc?

| 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.

Hmm, too bad.

| > | 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.

I don't think that it will work then, because spinning means not stuck at
a lock. I would try it anyway.

christos