Comments (14)
BurntSushi
commented on May 16, 2024
1
There hasn't been a release since this was fixed on master. Try compiling a recent checkout instead.
from ripgrep.
BurntSushi
commented on May 16, 2024
1
@cj Thanks for the report, but that's unfortunately not a valid reproduction. The panic is coming from devicon-lookup, not ripgrep.
Compare:
$ RUST_BACKTRACE=1 rg --files --no-ignore --hidden --follow --no-messages --glob '' | devicon-lookup | grep
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:743:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
with
$ rg --files --no-ignore --hidden --follow --no-messages --glob '' | RUST_BACKTRACE=1 devicon-lookup | grep
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:743:9
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:71
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: std::panicking::default_hook
at src/libstd/panicking.rs:211
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:474
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:381
6: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:336
7: std::io::stdio::_print
at src/libstd/io/stdio.rs:743
at src/libstd/io/stdio.rs:753
8: devicon_lookup::main
9: std::rt::lang_start::{{closure}}
10: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:293
11: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:87
12: std::rt::lang_start_internal
at src/libstd/panicking.rs:272
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
13: main
14: __libc_start_main
15: _start
If the bug were in ripgrep, then the first example would have shown a backtrace. In the second example, you can see at 8 that the panic passes through devicon_lookup::main.
from ripgrep.
coreyja
commented on May 16, 2024
1
@BurntSushi Thanks for the investigation! Sorry for causing noise on your repo and thanks so much for RipGrep!
from ripgrep.
houshuang
commented on May 16, 2024
Confirmed. Version 0.1.15, OSX (binary from site).
from ripgrep.
BurntSushi
commented on May 16, 2024
Bah, yup, bug.
from ripgrep.
mlsteele
commented on May 16, 2024
Sorry it's back. I think the panic is here now.
from ripgrep.
BurntSushi
commented on May 16, 2024
Please provide a reproduction.
…On Wed, Feb 20, 2019, 15:59 Miles Steele ***@***.*** wrote:
Sorry it's back. I think the panic is here
<https://github.com/clap-rs/clap/blob/master/src/errors.rs#L401> now.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAb34uMztCrT7_1bT0H4PdPtZLGWW2t2ks5vPbc-gaJpZM4KFPHu>
.
from ripgrep.
mlsteele
commented on May 16, 2024
$ git rev-parse HEAD
d9cf05ad50d976d55e2c5e1234fa3d03aad4bd66
$ export RUST_BACKTRACE=1
$ cargo run --help | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
thread 'main' panicked at 'Error writing Error to stdout: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', src/libcore/result.rs:997:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::_print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
9: clap::errors::Error::exit
10: cargo::exit_with_error
11: cargo::main
12: std::rt::lang_start::{{closure}}
13: std::panicking::try::do_call
14: __rust_maybe_catch_panic
15: std::rt::lang_start_internal
16: main
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.2
BuildVersion: 18C54
$ cargo --version
cargo 1.34.0-nightly (865cb7010 2019-02-10)
$ rustc --version
rustc 1.34.0-nightly (eac09088e 2019-02-15)
from ripgrep.
BurntSushi
commented on May 16, 2024
Why are you using cargo run? What happens when you use the binary directly? I would probably expect that bug to be in Cargo, not ripgrep. That --help flag is being given to Cargo. To give it to ripgrep, you would need cargo run -- --help I think.
(This is why providing a reproduction is always important.)
from ripgrep.
BurntSushi
commented on May 16, 2024
Yes, that backtrace points to Cargo, not ripgrep.
from ripgrep.
mlsteele
commented on May 16, 2024
Whoops. I was only using cargo (incorrectly) because I cloned the repo to poke around after seeing it another way.
cargo install
This is how I've been using ripgrep normally. As you can see it's nondeterministic but mostly panics.
$ cargo install ripgrep --force
...
Replacing /Users/miles/.cargo/bin/rg
$ ~/.cargo/bin/rg --version
ripgrep 0.10.0
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
$ ~/.cargo/bin/rg --help | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
$ ~/.cargo/bin/rg --help | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
thread 'main' panicked at 'Error writing Error to stdout: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', src/libcore/result.rs:997:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::_print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
9: clap::errors::Error::exit
10: clap::app::App::get_matches
11: rg::args::Args::parse
12: rg::main
13: std::rt::lang_start::{{closure}}
14: std::panicking::try::do_call
15: __rust_maybe_catch_panic
16: std::rt::lang_start_internal
17: main
github download
https://github.com/BurntSushi/ripgrep/releases
$ ~/Downloads/ripgrep-0.10.0-x86_64-apple-darwin/rg --version
ripgrep 0.10.0 (rev 8a7db1a918)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
$ ~/Downloads/ripgrep-0.10.0-x86_64-apple-darwin/rg --help | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
thread 'main' panicked at 'Error writing Error to stdout: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', libcore/result.rs:983:5
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: <unknown>
14: <unknown>
15: <unknown>
16: <unknown>
17: <unknown>
cargo run
fwiw cargo run -- --help | grep does not panic and cargo run -- --help outputs ripgrep's help not cargo's.
$ git rev-parse HEAD
d9cf05ad50d976d55e2c5e1234fa3d03aad4bd66
$ cargo run -- --help | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
Finished dev [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/rg --help`
from ripgrep.
cj
commented on May 16, 2024
@BurntSushi I am having the same issue even after building from master:
cj-osx ~/src/ripgrep ➤ 0913972|master✓
0:18 ± : ./target/release/rg --version ⏎ [16d7h42m]
ripgrep 0.10.0 (rev 0913972104)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
from ripgrep.
cj
commented on May 16, 2024
Steps to reproduce:
- cargo install devicon-lookup
- cd ~
- rg --files --no-ignore --hidden --follow --no-messages --glob "" | devicon-lookup | grep
cj-osx ~/apps
0:33 ◯ : rg --files --no-ignore --hidden --follow --no-messages --glob "" | devicon-lookup | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', libstd/io/stdio.rs:700:9
from ripgrep.
cj
commented on May 16, 2024
@BurntSushi that makes sense -- I will open a ticket in their repo.
Thank you for your response and taking a look!
from ripgrep.
Related Issues (20)
- rg spins in a nanosleep loop when one thread is blocked on a fifo
- [ignore] Fallback to use git check-ignore or support hook iteration HOT 3
- [feature request] Context up to a matching pattern instead of by fixed number of lines HOT 1
- ignore: WalkBuilder::build_parallel() example does not compile HOT 1
- FR: sort results by count HOT 1
- ripgrep does not properly apply ignore rules from .gitignore in parent directory
- global ignore / ripgreprc shell parameter expansion HOT 2
- unicode uppercase HOT 3
- Negation pattern/whitelisting is ignored from `--ignore-file` HOT 8
- .gitignore rule is matched incorrectly while in a subdir
- Adjacent replaced multiline matches result in wrong line numbers HOT 4
- Feature Request (globset): Expose `MatchStrategy` HOT 6
- Support decompression flags / smart use of zstd --long HOT 1
- Add `Select-String`/`sls` to the benchsuite HOT 6
- JSON indexing off HOT 4
- Feature Request: Early Bail Out for Time-Consuming Regex Matches in pcre2 HOT 4
- [perf] rg does not use globs to prune recursion when it can HOT 4
- cursor disappearing HOT 1
- failing test: f2361_sort_nested_files
- The same `LineTerminator` is being used for searching and printing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ripgrep.