'specified instant was later than self' from alacritty, rustc 1.33

[saethlin]

I'm running an odd system; Samsung Chromebook 3 (XE500C13) CELES with Linux galliumos 4.16.18-galliumos which is an alpha version. I'm on the ragged edge of hardware support.

Is this a bug that's fixable in std, or is my OS+hardware conspiring to break #56988?

I'm looking at this stack trace:

thread 'main' panicked at 'specified instant was later than self', src/libstd/sys/unix/time.rs:292:17
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:70
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   2: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:215
             at src/libstd/panicking.rs:478
   3: std::panicking::begin_panic
             at src/libstd/panicking.rs:412
   4: std::sys::unix::time::inner::Instant::sub_instant::{{closure}}
             at src/libstd/sys/unix/time.rs:292
   5: std::time::Instant::elapsed
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/result.rs:764
             at src/libstd/sys/unix/time.rs:291
             at src/libstd/time.rs:218
             at src/libstd/time.rs:307
             at src/libstd/time.rs:242
   6: alacritty::main
             at src/meter.rs:69
             at src/main.rs:104
   7: std::rt::lang_start::{{closure}}
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libstd/rt.rs:64
   8: main
   9: __libc_start_main
  10: _start

The responsible code in alacritty is

impl<'a> Sampler<'a> {
    fn new(meter: &'a mut Meter) -> Sampler<'a> {
        Sampler { meter, created_at: Instant::now() }
    }

    #[inline]
    fn alive_duration(&self) -> Duration {
        self.created_at.elapsed()
    }
}

[sfackler]

#56988 handled a specific set of targets known to have broken clocks. If your hardware also has a broken clock, it may need to be added to that set.

[saethlin]

I'm not entirely sure what target means here. I'm building for x86_64-unknown-linux-gnu, is that the target you're referring to?

[the8472]

out of curiosity, what do the following print?

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
grep flags /proc/cpuinfo

[saethlin]

╭ ➜ ben@galliumos:~
╰ ➤ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
╭ ➜ ben@galliumos:~
╰ ➤ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm 
╭ ➜ ben@galliumos:~
╰ ➤ grep flags /proc/cpuinfo
20:flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
47:flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat

[the8472]

Ok, so it reports tsc_reliable, which means the kernel thinks it it should be fine to use the rdtsc instruction as time source without further synchronization. But this flag can be overriden. Can you check your dmesg output regarding time sources and tsc and your /proc/cmdline whether tsc-related boot flags are set?

I'm not entirely sure what target means here. I'm building for x86_64-unknown-linux-gnu, is that the target you're referring to?

Yes, unix platforms were exempt from this fix because the linux kernel normally tries quite hard to make sure tsc is reliable and synchronized before choosing it as a clock source.

[saethlin]

I didn't see any relevant boot flags. I checked dmesg, and all I could find was something looking for tsc and deciding to use it.

Based on your reply I thought this might be a kernel bug, so I checked for updates, found one, and installed it. I can no longer reproduce the panic with the little test program I whipped up for this:

loop {
    let start = Instant::now();
    start.elapsed();
}

Seems it was a bug in the GalliumOS alpha kernel (little surprise there). Thanks for your help and insight on this issue.