acheronfail
Panics at repgrep-0.15.0/src/ui/tui.rs:45:41
When searching for a pattern over about 50G of log files after rgr found about 13k matches, it crashed with an unhandled panic:
thread '<unnamed>' panicked at /Users/pamburus/.cargo/registry/src/index.crates.io-6f17d22bba15001f/repgrep-0.15.0/src/ui/tui.rs:45:41:
failed to read event from terminal: Custom { kind: Other, error: "Failed to initialize input reader" }
stack backtrace:
0: 0x104ab91ec - __mh_execute_header
1: 0x1049c678c - __mh_execute_header
2: 0x104a8edc4 - __mh_execute_header
3: 0x104aba554 - __mh_execute_header
4: 0x104ab9d04 - __mh_execute_header
5: 0x104abb718 - __mh_execute_header
6: 0x104aba838 - __mh_execute_header
7: 0x104aba79c - __mh_execute_header
8: 0x104aba790 - __mh_execute_header
9: 0x104ac260c - __mh_execute_header
10: 0x104ac28b8 - __mh_execute_header
11: 0x10496bf78 - __mh_execute_header
12: 0x104970e68 - __mh_execute_header
13: 0x104abd170 - __mh_execute_header
14: 0x19469c2e4 - __pthread_deallocate
xargs: rgr: terminated with signal 6; aborting
I can reproduce on my dataset, but I don't know what triggers the issue and how to isolate it.
Can you build this from source and reproduce with debug logs? Let me know if you need guidance doing that. But just using the debug version should make the panic trace much more useful!
Here is rgr.log:
[2025-02-15 11:46:50.971980 +01:00] TRACE [src/main.rs:129] --- LOGGER INITIALISED ---
[2025-02-15 11:46:50.983422 +01:00] TRACE [/Users/pamburus/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mio-0.8.11/src/poll.rs:551] registering event source with poller: token=Token(0), interests=READABLE
[2025-02-15 11:46:51.008343 +01:00] ERROR [src/main.rs:230] An app error occurred: receiving on a closed channel
Here is the stderr output:
RUST_LOG=trace cargo run -- "$@"
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
Running `target/debug/rgr '\+00:00'`
thread '<unnamed>' panicked at src/ui/tui.rs:45:41:
failed to read event from terminal: Custom { kind: Other, error: "Failed to initialize input reader" }
stack backtrace:
0: 0x1029975b4 - std::backtrace_rs::backtrace::libunwind::trace::hbebc8679d47bdc2c
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
1: 0x1029975b4 - std::backtrace_rs::backtrace::trace_unsynchronized::h3a2e9637943241aa
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x1029975b4 - std::sys::backtrace::_print_fmt::he430849680584674
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:65:5
3: 0x1029975b4 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h243268f17d714c7f
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:40:26
4: 0x1029b3478 - core::fmt::rt::Argument::fmt::h0d339881c25f3c31
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/fmt/rt.rs:173:76
5: 0x1029b3478 - core::fmt::write::hb3cfb8a30e72d7ff
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/fmt/mod.rs:1182:21
6: 0x1029942ac - std::io::Write::write_fmt::hfb2314975de9ecf1
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/io/mod.rs:1827:15
7: 0x102998690 - std::sys::backtrace::BacktraceLock::print::he14461129ccbfef5
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:43:9
8: 0x102998690 - std::panicking::default_hook::{{closure}}::h14c7718ccf39d316
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:269:22
9: 0x1029982b4 - std::panicking::default_hook::hc62e60da3be2f352
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:296:9
10: 0x102999154 - std::panicking::rust_panic_with_hook::h09e8a656f11e82b2
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:800:13
11: 0x102998aa4 - std::panicking::begin_panic_handler::{{closure}}::h1230eb3cc91b241c
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:674:13
12: 0x102997a40 - std::sys::backtrace::__rust_end_short_backtrace::hc3491307aceda2c2
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:168:18
13: 0x10299876c - rust_begin_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
14: 0x1029cbb50 - core::panicking::panic_fmt::ha4b80a05b9fff47a
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
15: 0x1029cbf24 - core::result::unwrap_failed::h441932a0bca0dd7f
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:1679:5
16: 0x102578d80 - core::result::Result<T,E>::expect::hd97f0fef56399e1f
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:1059:23
17: 0x10255c234 - rgr::ui::tui::Tui::new::{{closure}}::ha019412ecf1b78c2
at /Users/pamburus/src/rust/third-party/repgrep/src/ui/tui.rs:45:27
18: 0x1025f5b90 - std::sys::backtrace::__rust_begin_short_backtrace::hb0b0234f39162d54
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:152:18
19: 0x1025679f4 - std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}::h9433fd943527e948
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/thread/mod.rs:538:17
20: 0x102580e30 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h334382e452b6e98e
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panic/unwind_safe.rs:272:9
21: 0x10257dc3c - std::panicking::try::do_call::h99a774efa9f64d0f
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:557:40
22: 0x102567bd0 - ___rust_try
23: 0x10256786c - std::panicking::try::h5234d035ac25f765
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:521:19
24: 0x10256786c - std::panic::catch_unwind::h7e243147a503bfb8
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panic.rs:350:14
25: 0x10256786c - std::thread::Builder::spawn_unchecked_::{{closure}}::h93c3d7c78fa93a6e
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/thread/mod.rs:537:30
26: 0x1025e44f0 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hc769e1b874de35de
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
27: 0x10299d268 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h01276ebbe54a8110
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/alloc/src/boxed.rs:2070:9
28: 0x10299d268 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::habad1faa89d23086
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/alloc/src/boxed.rs:2070:9
29: 0x10299d268 - std::sys::pal::unix::thread::Thread::new::thread_start::h1bd1b9c95010bf71
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/pal/unix/thread.rs:108:17
30: 0x1829a02e4 - __pthread_deallocate
An app error occurred: receiving on a closed channel
Logs available at: /var/folders/2g/x2xldyvd309_qg7p2qp7fmc00000gn/T/.repgrep
error: Recipe `dev` failed on line 28 with exit code 1
Oh.. I thought we might get some more information from that 😅 apparently not. It's failing here: https://github.com/acheronfail/repgrep/blob/master/src/ui/tui.rs#L45
Which, is after rg has run, and also after we've parsed all of its output JSON. 🤔 After that, we proceed to try to initialise the terminal UI... Seems strange to me that it would crash at that point?
I suppose we're assuming that your 13k of matches could be taking up some memory space... but why would crossterm be failing with that error. I don't really know why this would be happening either.
Any other information about your setup? We've got:
- files searched approx 50G
- approx 13k matches
rgseems to be working fine, as well as parsing its output- operating system?
- RAM size?
Not much more info to be gleaned from crossterm either: https://github.com/crossterm-rs/crossterm/blob/2c18768d2cee5b4c68a31c1ab23194030a6b7e7d/src/event/read.rs#L57
What's your stdin here? looking at crossterms's intialisation code there are a few branches around that. Are you running this in a terminal or spawning it or something else?
(I'm assuming you're on unix, and this code here and here is running). Either way, it seems that this error is to do with your terminal rather than the dataset.
Definitely only occurs when you use this dataset though? Doesn't also happen with smaller matches? 🤔
I narrowed this down to a file that triggers the issue. It is 235748 bytes and 1779 lines, but unfortunately I cannot share this file. The operating system is macOS 15.3, RAM size is 32 GiB.
This indeed depends on the input. If I pass the file to the stdin via shell's pipe or <filename stdin redirection, it fails.
But if I use shell command substitution <(cat filename), it does not.
Ok, I managed to narrow it down to a single line and synthesized an equivalent line that triggers the issue.
sample.log
2023-07-19T11:43:45.012305+00:00 [0x00002518] [0x00007f4ae2d038c0] [trace] [SomeObject] : SomeFunction() called.
And here is the command that reproduces the issue:
RUST_BACKTRACE=full just dev '\+00:00' <sample.log 2>stderr.log
I have tried three different terminals and it fails on all of them. So the problem does not seem to be terminal specific.
Actually, you were right that it is not dataset specific. It looks like it crashes on macOS in case of any matches when stdin is passed through pipe or stdin redirection. If there are no matches, it doesn't. If the filename is passed as a positional argument on the command line, it does not crash either.
It is curious, because initially when I discovered the crash on a large dataset, I used positional arguments, not stdin. And it still reproduces in that form also, and the backtrace and the log are the same.
I collected the list of the files which initially triggered the issue in files.lst.
Then I realized that using 00:00 pattern makes it easier to catch the issue since there are way more matches for this pattern.
Then I realized that it is enough to take a single file (3rd, exactly) from this file and pass it as a positional to the rgr to trigger the issue:
head -n 3 <files.lst | tail -n 1 | RUST_BACKTRACE=full xargs just dev '00:00' 2>stderr.log
But if I take that file name and pass it directly to just dev command, without all these head, tail and xargs, the issue does not reproduce despite the fact that the command is exactly the same and stdin is not used.
Probably the issue does not reproduce if stdin is connected directly to the terminal.
For example, this works just perfectly fine:
RUST_BACKTRACE=full just dev '00:00' $(cat files.lst) 2>stderr.log
With the whole initial 50GiB dataset. But if I use some additional commands with pipes and xargs to just collect the list of files that need to be passed as arguments, it crashes.