Closed Svenito closed 7 years ago
The line mentioned by the backtrace:
83: if t.update_time > Instant::now() {
84: thread::sleep(t.update_time - Instant::now());
85: }
I've also experienced these crashes but could never observe one in debug mode.
The subtraction calls effectively duration_since, which is documented with:
/// Returns the amount of time elapsed from another instant to this one.
///
/// # Panics
///
/// This function will panic if `earlier` is later than `self`, which should
/// only be possible if `earlier` was created after `self`. Because
/// `Instant` is monotonic, the only time that this should happen should be
/// a bug.
///
/// # Examples
///
/// ```no_run
/// use std::time::{Duration, Instant};
/// use std::thread::sleep;
///
/// let now = Instant::now();
/// sleep(Duration::new(1, 0));
/// let new_now = Instant::now();
/// println!("{:?}", new_now.duration_since(now));
/// ```
Yeah, same reaction I had. Some sort of weird clock skew or something? Let me know if want any more whelp debugging this. I just run it in the background while I work, so can capture debug
This has to be a stdlib bug, right? Instant::now()
is always created after t.update_time
. Only corner case, which should still work, is if t.update_time
was created in a different thread.
Sorry, I'm an idiot. The condition breaks in the nanosecond tick between the if and the subtraction. Should be fixed now.
Awesome. Will test as soon as I have time. Thanks
I run i3status fine but after some time it crashes. I've run it with a debug build of the latest master (1517618d) to provide a detailed stacktrace
System