Exa: Panic when `--long` is used

Created on 4 Jul 2019 · 27Comments · Source: ogham/exa

# exa v0.8.0

$ RUST_BACKTRACE=1 exa -l
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.33.0-src/src/libcore/slice/mod.rs:2455:10
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: __libc_start_main
  14: <unknown>
Aborted (core dumped)

errors › runtime error

Source

pangteypiyush

👍36

Most helpful comment

The crash is triggered by the update to tzdata 2019b. Rolling back to 2019a avoids it.

AluisioASG on 8 Jul 2019

👍10 🎉2

All 27 comments

Full backtrace, debug build from master as of today.
Problem seems to be in the dependency datetime, which looks to be pretty much unmantained.

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/slice/mod.rs:2539:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:61
   9: <usize as core::slice::SliceIndex<[T]>>::index
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/slice/mod.rs:2539
  10: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/slice/mod.rs:2396
  11: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/liballoc/vec.rs:1677
  12: zoneinfo_compiled::cook
             at /home/razielgn/.cargo/registry/src/github.com-1ecc6299db9ec823/zoneinfo_compiled-0.4.7/src/lib.rs:135
  13: zoneinfo_compiled::parse
             at /home/razielgn/.cargo/registry/src/github.com-1ecc6299db9ec823/zoneinfo_compiled-0.4.7/src/lib.rs:110
  14: <datetime::cal::zone::TimeZone as zoneinfo_compiled::CompiledData>::parse
             at /home/razielgn/.cargo/registry/src/github.com-1ecc6299db9ec823/zoneinfo_compiled-0.4.7/src/lib.rs:39
  15: zoneinfo_compiled::CompiledData::from_file
             at /home/razielgn/.cargo/registry/src/github.com-1ecc6299db9ec823/zoneinfo_compiled-0.4.7/src/lib.rs:32
  16: exa::output::table::determine_time_zone
             at src/output/table.rs:267
  17: exa::output::table::Environment::load_all
             at src/output/table.rs:249
  18: exa::options::view::<impl exa::output::table::Options>::deduce
             at ./src/options/view.rs:202
  19: exa::options::view::<impl exa::output::Mode>::deduce::{{closure}}
             at ./src/options/view.rs:40
  20: exa::options::view::<impl exa::output::Mode>::deduce
             at ./src/options/view.rs:93
  21: exa::options::view::<impl exa::output::View>::deduce
             at ./src/options/view.rs:18
  22: exa::options::Options::deduce
             at ./src/options/mod.rs:162
  23: exa::options::Options::parse
             at ./src/options/mod.rs:142
  24: <exa::Exa<'args, 'w, W>>::new
             at ./src/exa.rs:105
  25: exa::main
             at src/bin/main.rs:14
  26: std::rt::lang_start::{{closure}}
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64
  27: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:297
  28: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  29: std::rt::lang_start_internal
             at src/libstd/panicking.rs:276
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  30: std::rt::lang_start
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libstd/rt.rs:64
  31: main
  32: __libc_start_main
  33: _start

razielgn on 4 Jul 2019

Failed test cases:

options::view::test::views::ell
options::view::test::views::leg
options::view::test::views::lid
options::view::test::views::long

pangteypiyush on 4 Jul 2019

This seems to happen with only some specific timezone (exa read them from /etc/localtime).
On my side Asia/Tokyo and America/Los_angeles work just fine, but Asia/Shanghai and Asia/Hong_kong will cause the panic.

quinoa42 on 5 Jul 2019

👍4

Chipping in with timezone Australia/Melbourne and non-helpful backtrace:

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.33.0-src/src/libcore/slice/mod.rs:2455:10
stack backtrace:
0:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13: __libc_start_main
14:
fish: “env RUST_BACKTRACE=1 exa -al” terminated by signal SIGABRT (Abort)

karlpvoss on 5 Jul 2019

same question

Zheaoli on 5 Jul 2019

I believe I'm getting the same error with the Pacific/Auckland timezone and Exa 0.8.0 on Arch Linux.

severen on 6 Jul 2019

👍2

I'm having the same issue, if it's useful, my timezone is America/Lima, using ArchLinux
This is that I get while running exa -l and as the error message said, running with RUST_BACKTRACE=1 too

 exa -l
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.33.0-src/src/libcore/slice/mod.rs:2455:10
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[1]    7616 abort (core dumped)  exa -l

 export RUST_BACKTRACE=1                                                                                                             

 exa -l
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.33.0-src/src/libcore/slice/mod.rs:2455:10
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: __libc_start_main
  14: <unknown>
[1]    7916 abort (core dumped)  exa -l

c0x6a on 6 Jul 2019

👍4

As stated by @c0x6a, exa -l is crashing with timezone America/Lima, adding RUST_BACKTRACE=1 is useless since exa is compiled without debug information.

quebin31 on 7 Jul 2019

Happening here too with Australia/Sydney.

abusch on 8 Jul 2019

👍1

It fails for every timezone

from pytz import all_timezones
from re import match
from os import system


for tz in filter(lambda x: match(r'^[a-zA-Z/]+$', x), all_timezones):
    system('TZ=%s exa -l 2>/dev/null' % tz)

pangteypiyush on 8 Jul 2019

❤2 👍2

The crash is triggered by the update to tzdata 2019b. Rolling back to 2019a avoids it.

AluisioASG on 8 Jul 2019

👍10 🎉2

If don't want to downgrade, you may want to give lsd a try.

blackadress on 9 Jul 2019

👀4 🚀2

just noticed it today! seems like similar thingi

rhoit on 9 Jul 2019

Same here: America/Sao_Paulo

brunobertoldi on 9 Jul 2019

👍2

Same - Asia/Jerusalem

argamanza on 10 Jul 2019

Affects Europe/Minsk too

develop7 on 10 Jul 2019

This is affecting all my systems, across different timezones.

dessalines on 11 Jul 2019

👍1

I had the same problem, which seem to be fixed now? I had my time zone set to Europe/Berlin, but I am in Canada/Toronto right now. Since my arrival, exa -l paniced.

Today I updated my timezone (on Arch) via:

timedatectl set-timezone America/Toronto

and exa -l works again, without Panic. So maybe a work-around is to update your local timezone?

gruberb on 13 Jul 2019

Hey everyone,

Sorry about the wait on this crash. I can't get this to happen locally, but I'm investigating. If I really can't figure out the problem I can patch the zoneinfo-compiled crate to at least stop the crash from happening.

ogham on 13 Jul 2019

Could somebody who is experiencing this crash please upload (or e-mail me) their /etc/localtime? The datetime library seems to think that file is invalid. Whatever happens, I need to make it so an invalid file doesn't take the whole program down, but it would help if I had an example of a file it's having trouble with.

On Ubuntu, I have 2019b installed:

exa ~ $ apt show tzdata
Package: tzdata
Version: 2019b-0ubuntu0.16.04
...

and exa runs fine when setting it to the timezones people have been mentioning above.

ogham on 13 Jul 2019

Here's my timezone file that crashes exa:
Sydney.gz

abusch on 14 Jul 2019

Mine crashes too. Heres my /etc/localtime.

dsouzadyn on 14 Jul 2019

Time zone Asia/Shanghai panics, Asia/Tokyo doesn't. I change the time zone by modifying this line.

Time zone files I used:
Shanghai.gz
Tokyo.gz

weirane on 14 Jul 2019

The PR for zoneinfo-compiled linked above (https://github.com/rust-datetime/zoneinfo-compiled/pull/8) contains the relevant fix!

I could reproduce the crash with the uploaded Sydney and /etc/localtime files (thanks for all of those). After building again with the new version of zoneinfo-compiled, it doesn't crash anymore.

ogham on 14 Jul 2019

🎉8

Still open for me: 0.9.0 on MacOS, installed via brew.

$ exa -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[1]    42805 abort      exa -l

Looks like a different error than the one from OP though.

flypenguin on 26 Dec 2019

Still open for me: 0.9.0 on MacOS, installed via brew.

$ exa -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[1]    42805 abort      exa -l

Looks like a different error than the one from OP though.

Please open a new issue and include a reference to this one rather than trying to revive an issues that's long been closed.