GitHub Issue

linux_arm64 binary fails on 39-bit ARM64 kernels due to TCMalloc 48-bit VA assumption

Discovered On May 20, 2026

Primary Metric open

## Summary The `linux_arm64` `agy` binary aborts at startup on ARM64 systems whose kernel is configured with 39-bit user virtual addresses (`CONFIG_ARM64_VA_BITS=39`). This is related to #9, but the repro below is not Android/proot: it is a normal Linux ARM64 kernel with a 39-bit userspace VA configuration. The failure happens before CLI startup in TCMalloc's metadata arena. TCMalloc appears to generate tagged mmap hints assuming a 48-bit ARM64 VA space, so the reservations land above the address range accepted by this kernel. ## Repro environment - Device: ASUSWRT-Merlin router, GT-BE98 - Kernel: `Linux 4.19.294 aarch64` - Kernel config: - `CONFIG_PGTABLE_LEVELS=3` - `CONFIG_ARM64_VA_BITS_39=y` - `CONFIG_ARM64_VA_BITS=39` - Antigravity CLI version: `1.0.0` - Binary: native `linux_arm64` `agy` ## Observed error ```text third_party/tcmalloc/internal/system_allocator.h:595] MmapAligned() failed - unable to allocate with tag (hint=0x6cdb00000000, size=1073741824, alignment=1073741824) - is something limiting address placement? third_party/tcmalloc/internal/system_allocator.h:602] Note: the allocation may have failed because TCMalloc assumes a 48-bit virtual address space size; you may need to rebuild TCMalloc with TCMALLOC_ADDRESS_BITS defined to your system's virtual address space size third_party/tcmalloc/arena.cc:61] CHECK in Alloc: FATAL ERROR: Out of memory trying to allocate internal tcmalloc data (bytes=131072, object-size=16384); is something preventing mmap ...

View Raw Thread

Developer & User Discourse

hjotha • May 20, 2026

Additional validation from a local binary patch experiment:

I was able to make the same `linux_arm64` binary get past the TCMalloc startup failure on the 39-bit VA router by patching the inlined TCMalloc address/tag constants in the binary from a 48-bit layout to a 39-bit layout. This is not a suggested downstream workaround, but it is useful evidence for the root cause and for what the build needs to change.

The relevant generated constants in the binary matched the upstream TCMalloc logic:

- 48-bit build: `kAddressBits = 48`
- 48-bit tag shift: `kTagShift = min(48 - 4, 42) = 42`
- 48-bit tag mask: `kTagMask = 7

hjotha • May 20, 2026

Commands used to validate the workaround on the 39-bit VA router
----------------------------------------------------------------

The exact binary patch is intentionally not something I recommend users maintain manually, but these are the commands needed to run a VA39-patched `agy` binary once it exists.

On an ARM64 build host, build the ptrace shim:

```sh
git clone https://github.com/hjotha/ptrace-emu.git
cd ptrace-emu
make static
```

Copy the shim, the Antigravity ARM64 binary, and the glibc loader/libraries to the target device. My target uses `/mnt/routerdisk`:

```sh
mkdir -p /mnt/routerdisk/ptrace-emu
cp ptrace_emu.static /mnt/routerdisk/ptrace-emu/ptrace_emu
chmod +x /mnt/routerdisk/ptrace-emu/ptrace_emu

# These paths depend on how the linux_arm64 package was extracted.
cp agy.native-arm64.va39 /mnt/routerdisk/agy.native-arm64.va39
cp -a agy_libs /mnt/routerdisk/agy_libs
```

Patch `agy.native-arm64` itself (version-specific validation)
-------------------------------------...

MichaelWS • May 20, 2026

does your patch work?

hjotha • May 20, 2026

@MichaelWS yes, with the caveats above.

I validated it on my GT-BE98 running a 39-bit ARM64 userspace VA kernel. With the VA39-patched `agy.native-arm64` plus the ptrace shim and explicit glibc loader, both of these worked:

```text
/mnt/routerdisk/agy --version
# 1.0.0

/mnt/routerdisk/agy --help
# exits 0 and prints help
```

The important detail is that there are two separate issues:

- The ptrace shim handles missing ARM64 instructions on this older router CPU.
- The TCMalloc startup abort is separate and requires the binary itself to use the 39-bit address/tag layout. A partial patch that only changes `RandomMmapHint()` gets past the first mmap failure, but later fails in fast deallocation/tag checks. The tag/deallocation masks also have to move from the 48-bit/bit-42 layout to the 39-bit/bit-35 layout.

So yes, the patch works for the exact `agy.native-arm64` SHA I listed, but I would treat it only as validation of the root cause, not as a stable downstream workaround. The real ...

MichaelWS • May 20, 2026

Yes. that's easy enough to do.

On Wed, May 20, 2026 at 4:29 PM Henrique Jotha ***@***.***>
wrote:

> *hjotha* left a comment (google-antigravity/antigravity-cli#64)
>
>
> @MichaelWS yes, with the caveats above.
>
> I validated it on my GT-BE98 running a 39-bit ARM64 userspace VA kernel.
> With the VA39-patched agy.native-arm64 plus the ptrace shim and explicit
> glibc loader, both of these worked:
>
> /mnt/routerdisk/agy --version
> # 1.0.0
>
> /mnt/routerdisk/agy --help
> # exits 0 and prints help
>
> The important detail is that there are two separate issues:
>
> - The ptrace shim handles missing ARM64 instructions on this older
> router CPU.
> - The TCMalloc startup abort is separate and requires the binary
> itself to use the 39-bit address/tag layout. A partial patch that only
> changes RandomMmapHint() gets past the fi...