This issue was reported as early as November 2025. Why has it not been addressed by the official team yet?
Why does the server attempt to allocate memory in the 48-bit address range on Linux? Is the 39-bit address space (512GB) not sufficient for the language server’s operations?
On many ARM64 devices, the kernel is configured with 39-bit virtual addresses by default. When TCMalloc tries to map memory using a 48-bit hint, it triggers a fatal crash because the address is out of bounds for the CPU/Kernel configuration.
root@firefly:~# zcat /proc/config.gz | grep CONFIG_ARM64_VA_BITS CONFIG_ARM64_VA_BITS_39=y
# CONFIG_ARM64_VA_BITS_48 is not set
CONFIG_ARM64_VA_BITS=39
root@firefly:~# /home/<your user_name>/.antigravity-server/bin/1.20.6-135ccf460c67c4b900dc10aa71c978f27d78601c/extensions/antigravity/bin/language_server_linux_arm
3792438 third_party/tcmalloc/internal/system_allocator.h:589] MmapAligned() failed - unable to allocate with tag (hint=0x4dd740000000, size=1073741824, alignment=1073741824) - is something limiting address placement?
3792438 third_party/tcmalloc/internal/system_allocator.h:596] 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
3792438 third_party/tcmalloc/arena.cc:60] CHECK in Alloc: FATAL ERROR: Out of memory trying to allocate internal tcmalloc data (bytes=131072, object-size=16384); is something preventing mmap from succeeding (sandbox, VSS limitations)?
Here is the application error message.
