> Well, then someone should start debugging it.
I'm trying, but lacking 64-bit hardware I am reduced to debugging by
inspection.
> 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.
Thank you: I think that's it. I looked at the loop right away, but I
couldn't see how it could be getting stuck. It isn't: it's just looping
until the sun goes out.
> 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.
I will make those changes and also look some more for the source of the
"large value" (probably yet another LP64 bug).
> Maybe upstream could help here.
I already forwarded the bug of course, but upstream is not very active.
--
John Hasler
[EMAIL PROTECTED]
Elmwood, WI USA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
