Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64 #565

Closed
Relwi opened this issue Jan 16, 2023 · 26 comments
Closed
Labels
bug Something isn't working

Comments

@Relwi
Copy link

Relwi commented Jan 16, 2023

With the latest update 0.20.2, when I try to run the xplr command in the terminal, I'm getting this error:

thread 'main' panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64', library/std/src/sys/unix/time.rs:66:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
nushell: oops, process 'xplr' core dumped

OS: Arch Linux
Terminal: Alacritty
Shell: Nushell (I tried with Bash too but still the same error)
Rust: 1.66.1 stable
Compositor: Labwc (Wayland)

@sayanarijit
Copy link
Owner

Is your system time correct?

@Relwi
Copy link
Author

Relwi commented Jan 16, 2023

I think so, xplr was working in previous versions. Here is my timedatectl:

Local time: Mon 2023-01-16 12:52:48 CET
Universal time: Mon 2023-01-16 11:52:48 UTC
RTC time: Mon 2023-01-16 11:51:27
Time zone: Europe/Madrid (CET, +0100)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no

@sayanarijit
Copy link
Owner

sayanarijit commented Jan 16, 2023

Can you try in docker?

# Ubuntu
docker run -w / -it --rm ubuntu sh -uec '
  apt-get update -y
  apt-get install -y wget tar vim less
  wget https://github.com/sayanarijit/xplr/releases/latest/download/xplr-linux.tar.gz
  tar -xzvf xplr-linux.tar.gz
  ./xplr
'
# Arch
docker run -w / -it --rm archlinux sh -uec '
  pacman -Sy wget tar vim less
  wget https://github.com/sayanarijit/xplr/releases/latest/download/xplr-linux.tar.gz
  tar -xzvf xplr-linux.tar.gz
  ./xplr
'

@sayanarijit
Copy link
Owner

I guess System clock synchronized should be yes.

➜  ~ timedatectl
               Local time: Mon 2023-01-16 19:21:00 IST
           Universal time: Mon 2023-01-16 13:51:00 UTC
                 RTC time: Mon 2023-01-16 13:51:00
                Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

@Relwi
Copy link
Author

Relwi commented Jan 16, 2023

I tried with the System clock synchronized at yes and the NTP service activated but still the same problem.

It works in the Docker, so I'm gonna see what happens with the time on my machine.

@Relwi
Copy link
Author

Relwi commented Jan 16, 2023

I don't know, my time seems to be fine, I downloaded xplr from the releases and it gives me this error only in the 0.20.2 version, in the previous one 0.20.1 it works fine.

@sayanarijit
Copy link
Owner

Weird... Not sure if it matters, still what rust version are you using?

rustc --version

@Relwi
Copy link
Author

Relwi commented Jan 17, 2023

1.66.1

@justchokingaround
Copy link

facing same problem
image
image

@Relwi
Copy link
Author

Relwi commented Feb 10, 2023

Maybe was an unsuccessfull compilation or something? Because if I run xplr from the releases files it gives me this error too, but if I compile myself the project on the v0.20.2 tag it works fine.

@sayanarijit
Copy link
Owner

This is the gh release action: https://github.com/sayanarijit/xplr/blob/dev/.github/workflows/cd.yml#L79. Pretty standard.

@sayanarijit
Copy link
Owner

@Relwi
Copy link
Author

Relwi commented Mar 20, 2023

Same error on xplr-linux.tar.gz, but works fine on xplr-linux-musl.tar.gz

@Relwi
Copy link
Author

Relwi commented Apr 14, 2023

I formatted the PC and now is working, still don't know what caused this. Should we close this issue? @justchokingaround this issue still happens to you?

@justchokingaround
Copy link

i'm still getting the issue

@xfo-0
Copy link

xfo-0 commented Apr 20, 2023

I am also experiencing this issue.
OS: Arch Linux
Terminal: Wezterm (Also happens in Kitty or Alacritty)
Shell: Zsh w/ tmux (Also tried without tmux and just Bash as well but still the same error)
Rust: 1.68.2 stable (also when using 1.69.0)
Compositor: Sway

╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────
⫆ ~
╰⊚ timedatectl
               Local time: Thu 2023-04-20 12:15:43 PDT
           Universal time: Thu 2023-04-20 19:15:43 UTC
                 RTC time: Thu 2023-04-20 19:15:44
                Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

For build 'cargo build --release' using version 0.21.1 the output of 'RUST_BACKTRACE=full ./xplr/target/release/xplr 2>&1 | tee ~/tmp_xplr_log'

thread '<unnamed>' panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64', library/std/src/sys/unix/time.rs:77:9
stack backtrace:
  0:     0x55688ac0532c - std::backtrace_rs::backtrace::libunwind::trace::ha9053a9a07ca49cb
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
  1:     0x55688ac0532c - std::backtrace_rs::backtrace::trace_unsynchronized::h9c2852a457ad564e
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
  2:     0x55688ac0532c - std::sys_common::backtrace::_print_fmt::h457936fbfaa0070f
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys_common/backtrace.rs:65:5
  3:     0x55688ac0532c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h5779d7bf7f70cb0c
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys_common/backtrace.rs:44:22
  4:     0x55688ab2c88e - core::fmt::write::h5a4baaff1bcd3eb5
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
  5:     0x55688abd7ed4 - std::io::Write::write_fmt::h4bc1f301cb9e9cce
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/io/mod.rs:1684:15
  6:     0x55688ac07aef - std::sys_common::backtrace::_print::h5fcdc36060f177e8
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys_common/backtrace.rs:47:5
  7:     0x55688ac07aef - std::sys_common::backtrace::print::h54ca9458b876c8bf
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys_common/backtrace.rs:34:9
  8:     0x55688ac076ef - std::panicking::default_hook::{{closure}}::hbe471161c7664ed6
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:271:22
  9:     0x55688ac08769 - std::panicking::default_hook::ha3500da57aa4ac4f
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:290:9
 10:     0x55688ac08769 - std::panicking::rust_panic_with_hook::h50c09d000dc561d2
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:692:13
 11:     0x55688ac08214 - std::panicking::begin_panic_handler::{{closure}}::h9e2b2176e00e0d9c
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:581:13
 12:     0x55688ac081a6 - std::sys_common::backtrace::__rust_end_short_backtrace::h5739b8e512c09d02
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys_common/backtrace.rs:150:18
 13:     0x55688ac08191 - rust_begin_unwind
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
 14:     0x55688aaf9ce2 - core::panicking::panic_fmt::hf33a1475b4dc5c3e
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
 15:     0x55688aaf9ddc - core::panicking::panic::h9533b2fee90b999e
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:114:5
 16:     0x55688ac5dd94 - xplr::node::Node::new::hba1cc60dad75fdad
 17:     0x55688ac62864 - xplr::explorer::explore::he3362c057eb0eb48
 18:     0x55688ac616a0 - xplr::explorer::explore_sync::haa6e03744db5b356
 19:     0x55688ae0954d - std::sys_common::backtrace::__rust_begin_short_backtrace::h9cb81fabdd4bb7cc
 20:     0x55688ae093a0 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h64c9d4aaad63f72b
 21:     0x55688ac09ff5 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h39990b24eedef2ab
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/boxed.rs:1987:9
 22:     0x55688ac09ff5 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h01a027258444143b
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/boxed.rs:1987:9
 23:     0x55688ac09ff5 - std::sys::unix::thread::Thread::new::thread_start::ha4f1cdd9c25884ba
                              at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/sys/unix/thread.rs:108:17
 24:     0x7f87dbc40bb5 - <unknown>
 25:     0x7f87dbcc2d90 - <unknown>
 26:                0x0 - <unknown>

@dedguy21
Copy link

Getting similar error
xplr: 0.21.1
rustc: 1.68.2
Arch Linux kernel 6.2
thread '' panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64', libr
ary/std/src/sys/unix/time.rs:69:9

@sayanarijit
Copy link
Owner

Looks like it's related to rust-lang/rust#108277

@sayanarijit
Copy link
Owner

sayanarijit commented Apr 23, 2023

Apparently it's a filesystem/kernel bug, not related to xplr or other rust tools. Formatting the system might work, but doesn't guarantee it won't happen again. Until a solution is available, the best thing we can do now is find out exactly which systems are affected, and avoid them.

Fix: typo

@sayanarijit sayanarijit pinned this issue Apr 23, 2023
@sayanarijit sayanarijit changed the title Can't open xplr in terminal panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64 Apr 23, 2023
@sayanarijit sayanarijit added the bug Something isn't working label Apr 23, 2023
@bblacher
Copy link

bblacher commented Jul 21, 2023

Are there any news on this? I'd love to try this software but I can't even open it because of this.

@sayanarijit
Copy link
Owner

Looks like rust-lang/rust#108277 is still open, unfortunately.

@andrej1919
Copy link

Just installed xplr, similar error on Manjaro Linux:
thread '<unnamed>' panicked at 'assertion failed: tv_nsec >= 0 && tv_nsec < NSEC_PER_SEC as i64', library/std/src/sys/unix/time.rs:77:9 note: run with RUST_BACKTRACE=1`` environment variable to display a backtrace [1] 338179 IOT instruction (core dumped) xplr

Info on timestamp:
timedatectl Local time: sob 2023-11-11 22:56:31 CET Universal time: sob 2023-11-11 21:56:31 UTC RTC time: sob 2023-11-11 21:56:31 Time zone: Europe/Ljubljana (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no

@twinonetwintoo
Copy link

I don't think the OS doesn't matter. BTRFS & Rust combo is the issue somewhere.

@rbomze
Copy link

rbomze commented Feb 20, 2024

I found out what was the problem on my machine (running arch with btrfs as FS) . xlpr crashes when there is a file or directory in the folder you are launching it (most likely your users home folder when you launch it the first time :) and there is a file/folder with an invalid time inside this directory.
In my case the 'birth time' was way off (i think negative).
Just check with ls -la --time-birthtime. The only way to change it (touch is not capable of changing this time) was to copy it to a temporal location, delete the original and move the copied folder/file.
stat returns the birth time of a specific file.
unfortunately i was not able to use find to search for such occurrences, the parameter --newerBB did not work, falsely telling that the system does not provide a way to find the birth time of a file.
I suggest a 'soft check' with some output before the assert and the following panic, so that the user gets informed in some way what file caused the crash.

@bblacher
Copy link

rust-lang/rust#108277 is closed now, the fix will be in Rust 1.78.0

@sayanarijit
Copy link
Owner

Thank you all for your contributions. Closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants