Change:
https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0" <del> "@vscode/ripgrep@^1.15.2": version "1.15.2" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.2.tgz#85b55181353d6d204210e64e03853c5e2ee6edd9" integrity sha512-8zmyoxV6F+CY1Rinaq7LO/bGShaX2+B333X+Nqo984nC6jg2OvfZtQHzU+PKNQte2fjhm9h2ZlZTufnJxHaX9w== </del> <ins> "@vscode/ripgrep@^1.15.3": version "1.15.3" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.3.tgz#bd53c555ed7f2f546edc46a47d72b1914a5ba23d" integrity sha512-fCJP+4MRnhSTWw+GYAH93kSIomWYvdSe5206IqcHofBFcaFKR51XQNU0D5RB26Ps/5zRf5AQS26DIqqbMsB1Cw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

Discussion:
From Probably a regression from making aarch64-linux ripgrep build statically compiled to fix We might need to dynamically compile ripgrep instead of using musl, and find a container to compile it in. related // cc
Looks like jemalloc just needs to be configured with to support 16K page size. This can be achieved by setting the environment variable: (16K page size) Or to support 64K page size as well: (64K page size) In either case, it'd still work for 4K/16K(/64K) page sizes.
Do we have any good news on this? I found the similar thing happened before on other application like , probably we can use the same approach to solve this one?
Any update on this issue ?
Temporary Workaround: To address the issue until it is fixed, follow these steps: Install ripgrep and obtain its path. For Rocky Linux or any RHEL-based Linux distribution, run the following command with root privileges: For Ubuntu, use the following command: Alternatively, you can install ripgrep using Cargo: Verify the installation and retrieve the path by running: Replace the broken rg with a symlink by executing the following script. Please note that you should remove the echo commands to commit the changes: This workaround should help resolve the issue temporarily.
This should be fixed in tomorrow's VS Code Insiders. Please try it out and let me know if it works for you!
I tried but it seems not fixed or not included the fix. execute from the remote server(aarch64) and got <jemalloc: Unsupported system page size <jemalloc: Unsupported system page size memory allocation of 5 bytes failed find: ‘.vscode-server-insiders/bin//nodemodules/ terminated by signal 6 (after resetting the remote environment by deleting .vscode-server-insiders folder on the remote, and vscode reloaded. - 'Developer: Reload Window')
Are you running 16K page size or 64K?
I got $ getconf PAGESIZE on the aarch64 remote (Rocky Linux 8, aws r7g instance/Graviton3 processors).

Meanwhile, executing the same command above on x86-64 remote, I got the normal rg help print out as like error: The following required arguments were not provided: and correcting the hand typed typo above of vscode insider version info Version: 1.79.0-insider (user setup) Commit: Date: 2023-05-19T20:39:14.598Z Electron: 22.5.2 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
Hmm ok. I tried setting the env variable to increase max page size for jemalloc, but it seems to not be working. I'll try another approach.
If you let me know what you are attempting, I can also try out some stuff. Page size here is
Is this fixed in the latest release version of VScode? I just check on my arm64 container but it seems not working. VScode Version: 1.79.0 (Universal)
Same with Switched to newest insider build. . Problem not solved. Went to server, killed and deleted . Tried again to bootstrap. Problem is still NOT resolved. Search is still limited to open files.
!
Here is some useful link detailing what I think is the problem. Not sure if it is resolved by now. But if info from the discussion is current, I think you will have to either compile on the target system, or ship different precompiled versions of binary and select the correct one depending on the system specs (see ).
We do cross-compile for different systems for ripgrep I'll have to take another look.
So, my interpretation is, that the page-size is hard-coded into jemalloc. When the system page size at runtime differs from the one it is compiled for, it will fail. In other words, the one shipped right now fails out of the box: From your linked repo, I understand that you now focus on 16k page size. That would also not help me (if my suspicion is right), as my system's page size is: 64k
: Temporary fix. Bootstrap on target ARM system. You should have a directory called now. That is where the vscode server lives.

Download and compile : Replace binary deployed by with custom compiled version. Now search should work as expected.
can you check if the following runs fine on your aarch64 setup ? The build is generated from to use 64k for jemalloc.
Thanks built from source works for me!
can any of you verify this:
I untar-ed the file and the binary 'rg' is working good with remote search. (I sym-linked it with vscode 1.79)
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I can confirm it is fixed with the vscode insider downloaded a minute ago of (assume the commit hash changed since)
thanks so much for checking!