You are not logged in.
- Topics: Active | Unanswered
#1 2020-12-12 14:03:08
- doblerone
- Member
- Registered: 2011-12-08
- Posts: 215
[SOLVED] core dumped when using `exa` with --long option
Since I recently upgrade my system this morning, when I call in a terminal `exa --long` I get a core dumped:
─ ~
╰─ exa --long
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(3600s)',
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: abort (core dumped) exa --longOther options for `exa` such as `--all, --tree, --recurse, --group-directories-first` are working without problems.
If I use `ls -l`, which is equivalent to `exa -l`, there is no problem at all.
A bit more of context:
exa --version
exa v0.9.0
zsh --version
zsh 5.8 (x86_64-pc-linux-gnu)Last packages updated:
grep -i upgraded /var/log/pacman.log
[2020-12-12T08:25:17+0100] [ALPM] upgraded archlinux-keyring (20201028-1 -> 20201210-1)
[2020-12-12T08:25:21+0100] [ALPM] upgraded lz4 (1:1.9.2-2 -> 1:1.9.3-1)
[2020-12-12T08:25:21+0100] [ALPM] upgraded vulkan-icd-loader (1.2.158-1 -> 1.2.162-1)
[2020-12-12T08:25:21+0100] [ALPM] upgraded curl (7.73.0-1 -> 7.74.0-1)
[2020-12-12T08:25:21+0100] [ALPM] upgraded xorg-server-common (1.20.10-1 -> 1.20.10-2)
[2020-12-12T08:25:21+0100] [ALPM] upgraded xorg-server (1.20.10-1 -> 1.20.10-2)
[2020-12-12T08:25:22+0100] [ALPM] upgraded calibre (5.6.0-2 -> 5.7.1-1)
[2020-12-12T08:25:22+0100] [ALPM] upgraded ipset (7.7-1 -> 7.9-1)
[2020-12-12T08:25:22+0100] [ALPM] upgraded telegram-desktop (2.4.7-3 -> 2.4.7-4)
[2020-12-12T08:25:22+0100] [ALPM] upgraded xorg-server-devel (1.20.10-1 -> 1.20.10-2)
[2020-12-12T08:25:22+0100] [ALPM] upgraded xorg-server-xephyr (1.20.10-1 -> 1.20.10-2)
[2020-12-12T08:25:22+0100] [ALPM] upgraded xorg-server-xnest (1.20.10-1 -> 1.20.10-2)
[2020-12-12T08:25:22+0100] [ALPM] upgraded xorg-server-xvfb (1.20.10-1 -> 1.20.10-2)Coredump info
# coredumpctl info 59527
1 PID: 59527 (exa)
2 UID: 1000 (david)
3 GID: 1000 (david)
4 Signal: 6 (ABRT)
5 Timestamp: Sat 2020-12-12 14:53:15 CET (15min ago)
6 Command Line: exa --long
7 Executable: /usr/bin/exa
8 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-ab40e a2fc5ce4644ae4a544378ffb851.scope
9 Unit: user@1000.service
10 User Unit: app-org.kde.konsole-ab40ea2fc5ce4644ae4a544378ffb851.scope
11 Slice: user-1000.slice
12 Owner UID: 1000 (david)
13 Boot ID: ebbcc127eee1444e89ea91419b7b62db
14 Machine ID: 03586e0a7ca946db87e69ca3af1248db
15 Hostname: archpc
16 Storage: /var/lib/systemd/coredump/core.exa.1000.ebbcc127eee1444e89ea91419b7b62db.59527.16 07781195000000.zst
17 Message: Process 59527 (exa) of user 1000 dumped core.
18
19 Stack trace of thread 59528:
20 #0 0x00007f1a20674615 raise (libc.so.6 + 0x3d615)
21 #1 0x00007f1a2065d862 abort (libc.so.6 + 0x26862)
22 #2 0x0000555f03031f07 n/a (exa + 0x71f07)
23 #3 0x0000555f03031ef6 n/a (exa + 0x71ef6)
24 #4 0x0000555f0304d526 n/a (exa + 0x8d526)
25 #5 0x0000555f0304d363 n/a (exa + 0x8d363)
26 #6 0x0000555f0304ce7a n/a (exa + 0x8ce7a)
27 #7 0x0000555f02fd2110 n/a (exa + 0x12110)
28 #8 0x0000555f02fd4992 n/a (exa + 0x14992)
29 #9 0x0000555f03001378 n/a (exa + 0x41378)
30 #10 0x0000555f02fe7b7e n/a (exa + 0x27b7e)
31 #11 0x0000555f02fefae7 n/a (exa + 0x2fae7)
32 #12 0x0000555f03048415 n/a (exa + 0x88415)
33 #13 0x0000555f0304732c n/a (exa + 0x8732c)
34 #14 0x0000555f03058435 n/a (exa + 0x98435)
35 #15 0x00007f1a208233e9 start_thread (libpthread.so.0 + 0x93e9)
36 #16 0x00007f1a20737293 __clone (libc.so.6 + 0x100293)
37
38 Stack trace of thread 59527:
39 #0 0x00007f1a208296a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
40 #1 0x0000555f03052941 n/a (exa + 0x92941)
41 #2 0x0000555f0304a1b5 n/a (exa + 0x8a1b5)
42 #3 0x0000555f02ff2ac8 n/a (exa + 0x32ac8)
43 #4 0x0000555f0300c79b n/a (exa + 0x4c79b)
44 #5 0x0000555f0301b6ee n/a (exa + 0x5b6ee)
45 #6 0x0000555f0301dc4a n/a (exa + 0x5dc4a)
46 #7 0x0000555f03022b1b n/a (exa + 0x62b1b)
47 #8 0x0000555f03057cf3 n/a (exa + 0x97cf3)
48 #9 0x0000555f0301fae5 n/a (exa + 0x5fae5)
49 #10 0x00007f1a2065f152 __libc_start_main (libc.so.6 + 0x28152)
50 #11 0x0000555f02fcc13e n/a (exa + 0xc13e)
51
52 Stack trace of thread 59531:
53 #0 0x0000555f03048bba n/a (exa + 0x88bba)
54 #1 0x0000555f03048428 n/a (exa + 0x88428)
55 #2 0x0000555f0304732c n/a (exa + 0x8732c)
56 #3 0x0000555f03058435 n/a (exa + 0x98435)
57 #4 0x00007f1a208233e9 start_thread (libpthread.so.0 + 0x93e9)
58 #5 0x00007f1a20737293 __clone (libc.so.6 + 0x100293)
59
60 Stack trace of thread 59529:
61 #0 0x00007f1a208296a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
62 #1 0x0000555f03052941 n/a (exa + 0x92941)
63 #2 0x0000555f03048f05 n/a (exa + 0x88f05)
64 #3 0x0000555f03048428 n/a (exa + 0x88428)
65 #4 0x0000555f0304732c n/a (exa + 0x8732c)
66 #5 0x0000555f03058435 n/a (exa + 0x98435)
67 #6 0x00007f1a208233e9 start_thread (libpthread.so.0 + 0x93e9)
68 #7 0x00007f1a20737293 __clone (libc.so.6 + 0x100293)
69
70 Stack trace of thread 59530:
71 #0 0x00007f1a2082cdb0 __lll_lock_wait (libpthread.so.0 + 0x12db0)
72 #1 0x00007f1a20825743 __pthread_mutex_lock (libpthread.so.0 + 0xb743)
73 #2 0x0000555f02fe7b46 n/a (exa + 0x27b46)
74 #3 0x0000555f02fefae7 n/a (exa + 0x2fae7)
75 #4 0x0000555f03048415 n/a (exa + 0x88415)
76 #5 0x0000555f0304732c n/a (exa + 0x8732c)
77 #6 0x0000555f03058435 n/a (exa + 0x98435)
78 #7 0x00007f1a208233e9 start_thread (libpthread.so.0 + 0x93e9)
79 #8 0x00007f1a20737293 __clone (libc.so.6 + 0x100293)My attempt of debugging
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/exa...
(No debugging symbols found in /usr/bin/exa)
[New LWP 59528]
[New LWP 59527]
[New LWP 59531]
[New LWP 59529]
[New LWP 59530]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `exa --long'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f1a20674615 in raise () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f1a2034d640 (LWP 59528))]
(gdb) bt
#0 0x00007f1a20674615 in raise () from /usr/lib/libc.so.6
#1 0x00007f1a2065d862 in abort () from /usr/lib/libc.so.6
#2 0x0000555f03031f07 in ?? ()
#3 0x0000555f03031ef6 in ?? ()
#4 0x0000555f0304d526 in ?? ()
#5 0x0000555f0304d363 in ?? ()
#6 0x0000555f0304ce7a in ?? ()
#7 0x0000555f02fd2110 in ?? ()
#8 0x0000555f02fd4992 in ?? ()
#9 0x0000555f03001378 in ?? ()
#10 0x0000555f02fe7b7e in ?? ()
#11 0x0000555f02fefae7 in ?? ()
#12 0x0000555f03048415 in ?? ()
#13 0x0000555f0304732c in ?? ()
#14 0x0000555f03058435 in ?? ()
#15 0x00007f1a208233e9 in start_thread () from /usr/lib/libpthread.so.0
#16 0x00007f1a20737293 in clone () from /usr/lib/libc.so.6Could somebody help me to troubleshoot this?
Thx in advance.
Last edited by doblerone (2020-12-13 15:26:45)
Offline
#2 2020-12-13 03:34:58
- eschwartz
- Fellow
- Registered: 2014-08-08
- Posts: 4,097
Re: [SOLVED] core dumped when using `exa` with --long option
coreutils ls is a tool that has stood the test of time and works quite well. I personally don't see any reason to stop using it. 
Your issue is https://github.com/ogham/exa/issues/596 -- apparently, correctly listing files has exotic edge cases that these newfangled tools need to rediscover. 
It's supposedly fixed in exa-git.
(Note this has nothing to do with your system update, which did not update either exa or glibc.)
Given it took 7 months for the PR fixing it to be opened, and another 5 months to merge, the larger issue -- beyond "reinvent the wheel because rust and colors" -- is "do you trust this tool to be rigorously maintained"?
The maintainer basically did a "sudden reappearance" in October after being gone since January. You might think this is a hopeful sign, but January was itself a case of being gone since Jul 2019, then reappearing for 2 days to suddely merge tons of PRs, then, I guess, disappear again.
I've seen lots of people complain about this exact crash... I'm actually surprised this extremely long saga is coming to an end.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
#3 2020-12-13 08:11:11
- doblerone
- Member
- Registered: 2011-12-08
- Posts: 215
Re: [SOLVED] core dumped when using `exa` with --long option
Thx a lot @eschwartz for the explanation. My apologies for not checking github at first.
I'm closing this thread then.
Offline
#4 2020-12-13 13:11:49
- eschwartz
- Fellow
- Registered: 2014-08-08
- Posts: 4,097
Re: [SOLVED] core dumped when using `exa` with --long option
The thread has not been moderated into being impossible to submit new posts to, so I advise labeling the thread as "[Solved]" rather than "[Closed]".
The latter looks entirely too similar to the forum internal labeling for threads where the moderators have disabled posting.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline