Description
The ripgrep binary bundled with the Copilot CLI (<pkg-dir>/ripgrep/bin/linux-arm64/rg) statically links jemalloc built assuming a 4KB page size. On a kernel configured with a 16KB page size — the default on Asahi Linux (Linux-on-Apple-Silicon) — the binary aborts immediately instead of running, which breaks any Copilot CLI feature that shells out to ripgrep for file search.
Environment
copilot --version: GitHub Copilot CLI 1.0.88
- OS: Ubuntu on Asahi Linux, kernel
7.0.0-1002-asahi-arm (aarch64)
getconf PAGESIZE: 16384
- Affected path pattern:
~/.cache/copilot/pkg/linux-arm64/<version>/ripgrep/bin/linux-arm64/rg — reproduced on cached versions 1.0.83, 1.0.87, and 1.0.88, so this has been present across multiple releases.
Reproduction
$ getconf PAGESIZE
16384
$ echo hello | ~/.cache/copilot/pkg/linux-arm64/1.0.88/ripgrep/bin/linux-arm64/rg hello
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 160 bytes failed
Aborted (exit code 134)
file on the binary confirms it's statically linked (bundling its own allocator):
.../ripgrep/bin/linux-arm64/rg: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
For comparison, the distro's own rg (dynamically linked, uses glibc's allocator, no jemalloc) runs fine on the same machine — the crash is specific to this bundle's static jemalloc, not the kernel or the machine generally.
Expected
Any file-search feature that shells out to the bundled ripgrep should work on 16KB-page kernels, since ripgrep itself has no such restriction — this is purely a byproduct of how this specific prebuilt binary was compiled/linked.
Suggested fix
Either build the bundled ripgrep against a page-size-agnostic allocator (e.g. link the system allocator instead of a statically-linked jemalloc build pinned to 4KB pages), or fall back to a PATH-available rg/grep when the bundled binary fails to exec/aborts.
Workaround in use
Replacing the bundled rg at each cached version's ripgrep/bin/linux-arm64/rg with the system's dynamically-linked rg resolves the crash locally, but is undone on every CLI update since it re-fetches the broken bundle.
Description
The
ripgrepbinary bundled with the Copilot CLI (<pkg-dir>/ripgrep/bin/linux-arm64/rg) statically links jemalloc built assuming a 4KB page size. On a kernel configured with a 16KB page size — the default on Asahi Linux (Linux-on-Apple-Silicon) — the binary aborts immediately instead of running, which breaks any Copilot CLI feature that shells out to ripgrep for file search.Environment
copilot --version: GitHub Copilot CLI 1.0.887.0.0-1002-asahi-arm(aarch64)getconf PAGESIZE: 16384~/.cache/copilot/pkg/linux-arm64/<version>/ripgrep/bin/linux-arm64/rg— reproduced on cached versions 1.0.83, 1.0.87, and 1.0.88, so this has been present across multiple releases.Reproduction
fileon the binary confirms it's statically linked (bundling its own allocator):For comparison, the distro's own
rg(dynamically linked, uses glibc's allocator, no jemalloc) runs fine on the same machine — the crash is specific to this bundle's static jemalloc, not the kernel or the machine generally.Expected
Any file-search feature that shells out to the bundled ripgrep should work on 16KB-page kernels, since ripgrep itself has no such restriction — this is purely a byproduct of how this specific prebuilt binary was compiled/linked.
Suggested fix
Either build the bundled ripgrep against a page-size-agnostic allocator (e.g. link the system allocator instead of a statically-linked jemalloc build pinned to 4KB pages), or fall back to a PATH-available
rg/grepwhen the bundled binary fails to exec/aborts.Workaround in use
Replacing the bundled
rgat each cached version'sripgrep/bin/linux-arm64/rgwith the system's dynamically-linkedrgresolves the crash locally, but is undone on every CLI update since it re-fetches the broken bundle.