On Thu, Apr 24, 2008 at 02:21:39PM -0500, John Hasler wrote:
> Gabor writes:
> > That will be difficult since sometimes the bug does not hit for weeks and
> > then suddenly chrony starts to loop all the time.
>
> Are you saying that you have seen the bug?
Yes, see bug #447011. In fact, #474294 is a duplicate of #447011...
> > So I'd say go ahead and upload the new version to unstable, and if there
> > are no new occurances of the bug for 1-2 months then you can close it.
>
> Which would probably result in Chrony being removed from Lenny.
Well, then someone should start debugging it. The gdb trace sent by
Goshwin is quite promising. If UTI_NormaliseTimeval() is called with
x->tv_usec being a very large value (say LONG_MAX), that would clearly
explain the hang, and it would also explain why i386 does not seem to be
affected even if it is just as buggy as amd64: on i386, the while {}
loops execute at most 2147 times which is basically unnoticable, while
on amd64 that can be 2^32 times more.
So, IMHO turning the two while {} loops in UTI_NormaliseTimeval() into
divide/remainder operations should fix the hang. However, it still needs
investigation _why_ UTI_NormaliseTimeval() is being called with such a
bad time value, as it may be a result of a more severe bug like memory
corruption. Maybe upstream could help here.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3 : http://www.lpds.sztaki.hu
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
