[Bug]: ripgrep giving segfault and quietly making searches fail
See original GitHub issueIs there an existing issue for this?
- I have searched the existing issues
OS/Web Information
- Web Browser: Chrome
- Local OS: macOS
- Remote OS: Ubuntu
- Remote Architecture: x86_64
code-server --version
: 4.5.0
Steps to Reproduce
- Install
code-server
in the remote machine via conda-forge (mamba install code-server=4.5.0
) - attempt to execute the ripgrep binary included in this installation
- Also, after opening code-server and accessing via browser, try to search for a string in all files
Expected
- When executing
rg
, the binary executes (i.e. if you just execute/path/to/conda/env/share/code-server/lib/vscode/node_modules/@vscode/ripgrep/bin/rg
, you should get an error that no arguments were required - which is expected) - When searching for a string in all files, you should see all matches
Actual
- Get a segfault instead of observing that
rg
executes. - When searching for a string in all open files, only see matches in open files
Logs
Having trouble finding relevant logs doing this, but I have confirmed that if I install a working version of ripgrep (i.e. via mamba install ripgrep
and then replace the segfaulting binary rg
inside of share/code-server/lib/vscode/node_modules/@vscode/ripgrep/bin
with a symlink to this working version (which I tried based on #5216) then the search functionality works fine. So I’m pretty sure this is the source of the issue. I just don’t know WHY that binary gives a segfault.
Screenshot/Video
No response
Does this issue happen in VS Code or GitHub Codespaces?
- I cannot reproduce this in VS Code.
- I cannot reproduce this in GitHub Codespaces.
Are you accessing code-server over HTTPS?
- I am using HTTPS.
Notes
No response
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Unexpected segfault in a grep command - Stack Overflow
Any crash in user utilities, such as grep , cp , ls , etc. is a bug in said utility, and you should...
Read more >ripgrep 11.0.2 - Docs.rs
Namely, if a non-fatal error occurs during a search, then ripgrep will now always emit a ... One exception to this is if...
Read more >CHANGELOG.md - ripgrep - Fossies
BUG #1389: Fixes a bug where ripgrep would panic when searching a symlinked directory. BUG #1439: Improve documentation for ripgrep's automatic stdin detection....
Read more >Triagebot Notification Data - Rust
Comment on Login error covers login link · Comment on Add unstable `rustc-check-cfg` build script output · Comment on A project can not...
Read more >ChangeLog - ftp
Change the error when an overlay image is not writable into a warning that ... make distcheck * color-settings: Fix ColorSettings release *...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I was going to say that checksum mismatches on the binaries are not surprising, since conda builds everything from source. However, that’s clearly not what’s happening here. Something is very wrong:
Ah, I was thinking that since the
code-server
script Conda installs invokes plainnode
then depending on your path or the last version of Node you installed it could be the wrong version.But I realized that ripgrep segfaults when you run it directly so the version of Node has nothing to do with this anyway.
The sha256 does not match the release on GitHub so I am not sure what happened to it. There might be another part to the Conda build process I am missing.
Edit: fixed the paths; GitHub mangled them thinking they were email addresses.