Antigravity ACP SIGILL during Linux startup; CPU affinity avoids crash #28345

Activity

1. eljese

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 31, 2026
2. mikesulsenti commented on Nov 2, 2026

   

   mikesulsenti

   on Nov 2, 2026

   More actions

   Posted by Claude Opus 5.5 (Anthropic), an AI agent, on behalf of Mike Sulsenti, from his account and at his request. The measurements below were taken on his machine; the explanation of the cause is our interpretation.

   We hit the same crash and found what looks like the deciding factor: the CPU ID the runtime starts on, not timing. It crashes whenever the ID is at or above the number of CPUs the container shows. That would also explain why taskset -c 0-2 works.

   Environment

   • T3 Code v0.1.6 (systemd user service), managed runtime agy-acp-server-1.4.1-linux-x86_64.zip (sha256 2e37012c…7871384, matches the hash T3 pins)
   • Privileged Proxmox LXC (kernel 7.0.14-25-pve, Arch Linux), AMD Ryzen 9 9950X (Zen 5: AVX2, AVX-512, AES, VAES, SHA all present), so this is not a missing-instruction problem
   • Managed install from provider settings fails with "The downloaded Antigravity runtime could not start in this environment."

   Key observation

   The LXC gets a sparse host cpuset, but lxcfs shows a smaller, renumbered CPU count:

   Cpus_allowed_list / cpuset.cpus.effective : 1-2,5-11,15,17-21,24,26-28,31
   nproc / getconf _NPROCESSORS_ONLN         : 20
   /proc/cpuinfo processors                  : 0..19
   getconf _NPROCESSORS_CONF                 : 32
   

   The SIGILL report names CPU IDs that are ≥ 20 every time it gives one (received by PID … on cpu 21, on cpu 27). Our stack trace differs from yours (absl::Uniform<>() ← placer::common::FileSetManagerFactory::Options::Options() ← placer::client::…InitFactory() ← GoogleInitializer::RunInitializers()), but it is the same kind of deliberate ud2 trap during startup (si_code=2).

   A/B test

   This is your initialize probe, with launches interleaved, official 1.4.1:

   affinity	initialize OK	SIGILL (exit 132)
   unrestricted (1-2,5-11,15,17-21,24,26-28,31)	0/5	5/5
   allowed CPUs with ID < 20 (1,2,5-11,15,17-19)	5/5	0/5
   allowed CPUs with ID ≥ 20 (20,21,24,26-28,31)	0/5	5/5

   Through the wrapper below, 7/7 more probes initialized, and after pointing T3 at the wrapper, the provider came up in T3 Code (confirmed by the owner in the UI).

   Our guess (not verified in the binary): something in Google's startup code sizes a per-CPU table from the visible CPU count, then indexes it by the real CPU ID (sched_getcpu()). When the ID is past the end of the table, a bounds or null check fires. On a host where CPU IDs are contiguous from 0, this never happens. That's probably why it mostly hits Proxmox/LXC users with a cores limit, where the cpuset is often sparse. Your 4/12 success rate without pinning fits this: sometimes the process happens to land on a low ID.

   Workaround

   This is the same approach as yours, but the CPU list is worked out at each launch: allowed CPUs with IDs below the visible count. That way it still works if the host reassigns the container's CPUs. Put the official agy_acp_server.par and localharness_external in one directory. Put this wrapper in a second directory, plus a symlink named localharness_external pointing at the real one (T3 checks that file is next to the executable's real path). Then set Custom ACP executable path to the wrapper. T3 picks up the change with no restart.

   #!/bin/bash
   # Run the official runtime pinned to allowed CPUs whose IDs are below the visible CPU count.
   set -u
   REAL="${ANTIGRAVITY_ACP_REAL:-$HOME/.local/opt/antigravity-acp/1.4.1/agy_acp_server.par}"
   cpus="${ANTIGRAVITY_ACP_CPUS:-}"
   if [ -z "$cpus" ]; then
     allowed=$(awk '/^Cpus_allowed_list:/ {print $2}' /proc/self/status)
     limit=$(/usr/bin/nproc)
     picked=()
     IFS=, read -ra parts <<<"$allowed"
     for part in "${parts[@]}"; do
       lo=${part%-*}; hi=${part#*-}
       for ((c = lo; c <= hi; c++)); do ((c < limit)) && picked+=("$c"); done
     done
     cpus=$(IFS=,; echo "${picked[*]:-}")
   fi
   [ -n "$cpus" ] && exec /usr/bin/taskset -c "$cpus" "$REAL" "$@"
   exec "$REAL" "$@"

   Trade-offs: Antigravity and everything it starts (agent shell commands, builds) run on fewer CPUs (13 of 20 here), and T3 no longer updates the runtime automatically.

   Possible fixes on the T3 side

   • When the runtime exits with SIGILL during validation on Linux, check whether the allowed CPU IDs go past the visible count. If they do, retry with the runtime pinned to the IDs below it, or at least explain this in the error instead of the generic "could not start in this environment".
   • Since the crash is in Google's binary, it may also be worth passing the CPU-ID finding to the Antigravity team.
3. chenydev commented on Nov 10, 2026

   

   chenydev

   on Nov 10, 2026

   Last edited by chenydev

   More actions

   Drafted with Claude Code (Anthropic) on my behalf; the measurements below were taken on my machine.

   Edit (2026-11-10): narrowed down the cause, and there is a working workaround. The original report is collapsed at the bottom.

   Summary

   On machines whose online CPU IDs are not contiguous from 0 (here some cores are offline on purpose), agy_acp_server.par 1.4.5 aborts at startup with SIGILL. It is not a missing CPU instruction. The server appears to size per-CPU data by the count of online CPUs but index it by CPU ID. With holes in the numbering, an index goes out of range and a bounds check traps with ud2. T3 then reports the generic "The downloaded Antigravity runtime could not start in this environment."

   taskset alone cannot fix this. I found a workaround that needs no root and does not change host CPU state (below).

   Environment

   • T3 Code 0.1.7 (desktop), managed runtime agy-acp-server-1.4.5-linux-x86_64.zip (sha256 923923a0…5188013b, matches the pinned hash)
   • NixOS, kernel 7.2.2 (CachyOS), glibc 2.42, nix-ld; AMD Ryzen 7 6800H
   • CPU state:

   possible: 0-15      present: 0-15
   online:   0-1,4-9,12-15
   offline:  2-3,10-11
   nproc = 12, _NPROCESSORS_CONF = 16, _NPROCESSORS_ONLN = 12
   

   Likely cause (inferred from the server's own crash output and the experiments below)

   1. The server's crash handler shows that the SIGILL is a ud2 trap inside eventmanager::TopologyHelper::InitStealOrders(), called from EventManager2::EventManager2(). That is the pattern a hardened-libc++ bounds check produces, not an unsupported instruction. In the register dump the server prints, the loop index is 2 (an offline CPU here) and the looked-up value is -1, which looks like an index for a CPU missing from the topology.
   2. When I make the CPU count and the CPU IDs disagree in other ways, the server reports it explicitly: Check failed: num_cpus == t->NumCPUs() (16 vs. 12) at eventmanager2.cc:1186.
   3. Under a debugger I sometimes see the same kind of trap even earlier, in a static initializer: concurrent::percpu::PerCpu<absl::InsecureBitGen> ← colossus::Feature<bool>::Feature(). That fits per-CPU tables sized by the online count (12) being indexed by the current CPU ID (up to 15).

   So the server seems to assume that every CPU ID < number of online CPUs, and that this count equals the affinity mask size. Both are false when online CPU IDs have gaps.

   Experiments (unprivileged user+mount namespace, bind-mounting files under /sys/devices/system/cpu)

   setup	result
   unpinned / taskset -c 0-1,4-9 / taskset -c 12-15	SIGILL in InitStealOrders (5/5 each)
   --eventmanager2_use_sys_topology	same SIGILL in InitStealOrders
   hide offline cpuN dirs, possible/present = online list	same SIGILL
   offline CPUs shown as online=1 with a synthesized topology/	Check failed: num_cpus == t->NumCPUs() (12 vs. 1) (eventmanager2.cc:1186)
   online shown as 0-15	Check failed: num_cpus == t->NumCPUs() (16 vs. 12); the topology appears to be capped by the affinity mask, and the kernel will not let you pin to offline CPUs
   taskset -c 0-1 + online shown as 0-1	initialize OK 8/8; T3's validation checks all pass (agentInfo antigravity-acp / 1.4.5, protocol 1, loadSession, resume, auth.logout, oauth-personal); authenticate produces the Google sign-in URL through T3's BROWSER helper as expected

   With IDs 0-1,4-9,12-15, the only consistent view is a contiguous prefix of the online IDs starting at 0, which here is {0,1}.

   Workaround (no root; host CPU state unchanged)

   Set these as T3's Custom ACP executable path (.../agy_acp_server.par). Put them in a directory with the official runtime extracted to $AGY_REAL_RUNTIME.

   agy_acp_server.par:

   #!/usr/bin/env bash
   here=$(dirname "$(readlink -f "$0")")
   AGY_CPU_VIEW_ONLINE=0-1 exec taskset -c 0-1 "$here/agy-cpu-view" "$AGY_REAL_RUNTIME/agy_acp_server.par" "$@"

   agy-cpu-view (private user+mount namespace; only /sys/devices/system/cpu/online changes, the program still runs as your uid):

   #!/usr/bin/env bash
   set -euo pipefail
   if [[ "${_AGY_CPU_VIEW_INNER:-}" != 1 ]]; then
     exec unshare --user --map-root-user --mount --propagation private \
       env _AGY_CPU_VIEW_INNER=1 _AGY_UID="$(id -u)" _AGY_GID="$(id -g)" "$0" "$@"
   fi
   f=$(mktemp); printf '%s\n' "${AGY_CPU_VIEW_ONLINE:?}" > "$f"
   mount --bind "$f" /sys/devices/system/cpu/online
   unset _AGY_CPU_VIEW_INNER
   exec unshare --user --map-user="$_AGY_UID" --map-group="$_AGY_GID" -- "$@"

   localharness_external (a static Go binary that is not affected; this wrapper restores full affinity so agent tool runs are not limited to 2 cores):

   #!/usr/bin/env bash
   exec taskset -c "$(cat /sys/devices/system/cpu/possible)" "$AGY_REAL_RUNTIME/localharness_external" "$@"

   Costs: the ACP server process itself is limited to 2 CPUs, and you need unprivileged user namespaces. So far I have only verified initialize and the start of the sign-in flow; full sessions are still to test.

   Corrections to my original comment

   • The custom ACP path does not run T3's strict validation (that only runs for the managed install). It does need a localharness_external sibling, and T3 always passes --uid= on Linux. The nixpkgs agy acp (1.5.3) rejects --uid= and uses different session mode IDs (accept-edits; auto_edit/yolo are rejected), so it is not a drop-in replacement either.

   Suggested fixes

   • Antigravity runtime (Google): size per-CPU tables by the highest possible CPU ID + 1 (/sys/devices/system/cpu/possible, _NPROCESSORS_CONF) rather than the online count, or map CPU IDs to dense indexes. Also handle topology lookups that return -1 for CPUs not present in the topology (offline CPUs).
   • T3: include the runtime's stderr (SIGILL … InitStealOrders) in the "could not start in this environment" error. A documented hook for a launcher or wrapper around the managed runtime would also make workarounds like the one above easier.

   Original comment

   Another data point: I hit the same "The downloaded Antigravity runtime could not start in this environment." on bare metal, and here taskset does not help. The crash seems tied to the CPU topology (offline cores) rather than to which CPU the process is scheduled on.

   affinity	initialize OK	SIGILL
   unpinned	0/5	5/5
   taskset -c 0-1,4-9 (IDs < nproc)	0/5	5/5
   taskset -c 12-15 (IDs >= nproc)	0/5	5/5

   *** SIGILL ..., si_code=2 ... received by PID ... on cpu 0
   PC: eventmanager::TopologyHelper::InitStealOrders()
       FailureSignalHandler()
   

   Interpretation at the time (narrowed down above): with non-contiguous online CPUs, something in InitStealOrders() indexes by CPU ID or assumes the configured and online counts match. I did not bring the offline cores back online to confirm, since they are offline on purpose.
4. derhub commented on Nov 14, 2026

   

   derhub

   on Nov 14, 2026

   More actions

   Another confirmed case: bare-metal Intel hybrid CPU, CPUs taken offline on purpose

   • T3 Code 0.1.9 (local server, Linux), managed runtime agy-acp-server-1.4.5-linux-x86_64.zip (sha256 matches the pinned 923923a0…5188013b)
   • Fedora, kernel 7.3.3, Intel Core i9-13900KF (8P+16E, 32 threads), bare metal
   • CPUs 8–9 (one P-core) are offline because the hardware is faulty, and isolcpus=8,9 is set: online: 0-7,10-31, offline: 8-9

   Install fails with "The downloaded Antigravity runtime could not start in this environment." The same crash also breaks Antigravity branch-name generation (TextGenerationError: … Antigravity text generation failed ← AcpProcessExitedError: ACP process exited after signal SIGILL). The stack trace is the one above: SIGILL si_code=2 in eventmanager::TopologyHelper::InitStealOrders() ← EventManager2::EventManager2().

   setup	result
   runtime run directly	SIGILL, exit 132
   @chenydev's namespace wrapper with online shown as 0-7 plus taskset -c 0-7	initialize OK 5/5

   With the wrapper set as the Antigravity Binary path, T3 picked it up without a restart and the provider shows ready (1.4.5, authenticated).

   So this isn't specific to AMD or containers: any gap in the online CPU IDs triggers it. Users who turn off a degraded Raptor Lake core are likely to hit it. It would help if T3 detected an online CPU list with gaps when the runtime exits with SIGILL, and named that cause instead of showing the generic error.

   Drafted by Claude Opus 5.5 (Claude Code) during t3 triage, on the reporter's behalf; the measurements were taken on their machine.