Time::precise_time_ns is overflowing today in WSL

This is WSL. I did not know there was a WSL2 !

This PC never sleeps.

I have never noticed my Linux time being off. Sadly I did not think to check when the problem showed up. Now that I have rebooted the problem is gone and my Linux time is fine.

Instant just directly stores the result as secs + nsecs and manipulates them together, so as long as you don't attempt to do a similar calculation with it (which it doesn't provide an API for) you can't cause that same panic. When you call elapsed it will calculate the duration between the start point and now for you, which should give a small value, as long as CLOCK_MONOTONIC is working correctly.

2 Likes

I have always naively assumed that the tv_nsec field returned by clock_gettime() was always between 0 and 999,999,999. After all, why would you need more than that when you have a field for seconds as well?

Which seems to be true:

$ cat src/main.rs
extern crate time;

use time::precise_time_ns;

fn main() {
    loop {
        let start_time = precise_time_ns();
        println!("{}", start_time);
    }
}
$ cargo run --release
...
ts.tv_sec = 11033
ts.tv_nsec = 997605000
11033997605000
ts.tv_sec = 11033
ts.tv_nsec = 999395000
11033999395000
ts.tv_sec = 11034
ts.tv_nsec = 1116000
11034001116000
ts.tv_sec = 11034
ts.tv_nsec = 8102000
11034008102000
...

The mystery is, why where both tv_sec and tv_nsec negative here this morning?

tv_nsec not being in the range 0..999,999,999 definitely points at a bug instead of expected behavior (what does it even mean if it's outside this range?)

this seems to describe your bug (both tv_sec and tv_nsec negative): https://github.com/microsoft/WSL/issues/3840

1 Like

Yes, thanks.

Although following those discussions around it look like this should have been fixed already.

Another clue here is that I now notice Windows had a failed update yesterday afternoon. Perhaps that messed things up.

1 Like