JVM64bit running on Linux 64bit: when system time changes the JVM may hang (bug_id=6900441)

[Andrew Haley]

On 09/02/2013 04:44 PM, bruno bossola wrote:

> Thanks for your answer.  That's probably correct in the sense this is what
> the code is doing :) I won't discuss that at all.
> 
> However pthread_cond_timedwait uses by default, as clock id, CLOCK_REALTIME
> which, unfortunately is affected by settime()/settimeofday() calls (on
> Linux): for that reason it cannot be used to measure nanoseconds delays,
> which is what the specification requires. CLOCK_REALTIME is not guaranteed
> to monotonically count as this is the actual "system time": each time my
> system syncs time using a NTP server on the net, the time might jump
> forward or backward. The correct call (again on Linux)  would require to
> use CLOCK_MONOTONIC as clock id.
> 
> Your point would be that, based on Posix specs, setting the value of the
> CLOCK_REALTIME clock using clock_settime() should have no effect on threads
> that are waiting. Is that correct?

The first thing I had to do was understand what was going on.

Secondly, what could be done to fix it?  pthread_cond_timedwait() uses
the real-time clock.  That's not just by default: as far as I can see
there's no way to make it use any other clock.  So, fixing this
problem requires some reengineering, not just replacing CLOCK_REALTIME
with CLOCK_MONOTONIC.

Finally, I had to ask "Is this an important bug?"  I don't think it
is, and David Holmes allowed been much more than I would have done.
If you make the time go backwards in a big jump, all manner of things
in a Unix system will go wrong.  In particular, timestaps on files
will be affected, and anything that relies on such things will be
affected too.  Anyone with root privileges should know this.

The right answer in the short term is to use NTP at boot, so that
systems are not provoked in this way.

Andrew.