Panic on mundane-looking input

[bgeron]

What version of ripgrep are you using?

ripgrep 13.0.0
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

How did you install ripgrep?

With cargo install --force --features pcre2, on 6 December 2021.

What operating system are you using ripgrep on?

macOS 12.0.1 on x64 MacBook Pro, 9th generation Intel

Describe your bug.

Panic on a normal-looking input.

What are the steps to reproduce the behavior?

In bash, run echo -e "four\n/a " | rg -w a?.

On my Linux machine, I cannot reproduce. On my Mac, it reproduces reliably every time.

What is the actual behavior?

/Users/bram.geron/.config/ripgreprc: No such file or directory (os error 2)
DEBUG|grep_regex::word|/Users/bram.geron/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/grep-regex-0.1.9/src/word.rs:52: word regex: "(?:(?m:^)|\\W)(a?)(?:\\W|(?m:$))"
DEBUG|globset|/Users/bram.geron/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/globset-0.4.8/src/lib.rs:421: built glob set; 0 literals, 0 basenames, 12 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
thread 'main' panicked at 'assertion failed: self.start <= end', /Users/bram.geron/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/grep-matcher-0.1.5/src/lib.rs:131:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/core/src/panicking.rs:101:14
   2: core::panicking::panic
             at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/core/src/panicking.rs:50:5
   3: <grep_regex::word::WordMatcher as grep_matcher::Matcher>::find_at
   4: <grep_regex::matcher::RegexMatcher as grep_matcher::Matcher>::find_at
   5: <&M as grep_matcher::Matcher>::find_iter_at
   6: grep_printer::util::find_iter_at_in_context
   7: <grep_printer::standard::StandardSink<M,W> as grep_searcher::sink::Sink>::matched
   8: grep_searcher::searcher::core::Core<M,S>::match_by_line
   9: grep_searcher::searcher::glue::ReadByLine<M,R,S>::run
  10: grep_searcher::searcher::Searcher::search_reader
  11: rg::search::SearchWorker<W>::search
  12: rg::try_main
  13: rg::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[bgeron]

A friend with Linux informs me that it reproduces for him. So perhaps this fails on Intel, but works on AMD.

[BurntSushi]

Unfortunately, I cannot reproduce this issue, even on macOS and even when installing in the same manner as you. Could you try using cargo build --release --features pcre2 in a checkout of this repo with the latest version of stable Rust? Does it still panic? I'm wondering if this is a version mismatch issue somehow.

Also, can you clarify whether you literally ran cargo install --force --features pcre2 or not? Because that doesn't work on the latest stable version of Rust, even when you're in a checkout of this repo. You need either cargo install --force --features pcre2 ripgrep or cargo install --force --features pcre2 --path ..

Can you also check whether the release binaries on this repo reproduce this issue for you?

[BurntSushi]

Ah, this is a duplicate of #1891. It will be fixed in the next release.

If you install from master (e.g., cargo install --force --features pcre2 --path .), then this should be fixed.

[BurntSushi]

I was ultimately able to reproduce this by running cargo install --force --features pcre2 ripgrep, which builds ripgrep using the latest versions of each of its dependencies. Since the fix for #1891 hasn't been published yet, it doesn't pick it up.

[bgeron]

Oops, I meant to write cargo install --force --features pcre2 ripgrep. I can also reproduce it on the Mac with merely the binary generated by cargo install --force ripgrep. In both cases, I was using Rust 1.56.0 stable.

The release binary reproduces it too for me.

[bgeron]

Ah it's been fixed.. thanks! For everything.