Beagle SCM

GIT-021: linux-scale checkout dies mid-reconcile with git.tree: bad tree entry + a 1.7 GB anon spike — store content verifies CLEAN post-hoc (stateful read bug, pre-existing)

A jab get clone of a linux-v3.0-scale repo (698 MB pack, 2.06 M objects) lands + indexes the pack fine and STARTS the checkout, then dies in reconcileDir → treeMap → readTree with Error: git.tree: bad tree entry (_git_tree_next@[native code]) — and the process' ANONYMOUS RSS explodes from 48 MB to 1.75 GB in the final 5 s before the throw (a garbage size feeding a giant alloc, then the bad parse). The landed store is NOT corrupt: a FRESH process walks the same baseline tree completely (2265 trees, every readTree OK). So the bug is STATE accumulated inside the long-running get process (a shared/reused Buf or resolve window poisoned after ~10^5 interleaved getObject/materialise calls), not the pack, not the index, not GET-044 streaming. Method: work.

Input

Context

• Repro 2026-07-14 (deterministic, twice): single-branch bare fixture at linux v3.0 (git clone --bare --single-branch off a local mirror; 733 MB closure, ~2.06 M objects), served via git-upload-pack over an ssh shim; jab get 'ssh://…?/linux'. Pack lands as 0000000001.keeper 697.7 MB + a 31.4 MB idx run + refs; root files materialise (COPYING, Makefile, …); then the throw.
• PRE-EXISTING: the identical clone with the PRISTINE (pre-GET-044) in-memory wire path fails at the SAME point with the SAME error — streaming did not introduce it, it only made the phase visible with flat memory.
• Store exonerated: post-fail, a fresh store.open(...) + full depth-first readTree walk of the tip's tree = 2265 trees, ZERO failures. buildIndex's scan also passed (the idx run was written).
• RSS timeline (0.3 s sampling, anon column): flat 35 MB through the 200 s transfer, flat through the 130 s index build, 48 MB through the first 40 s of checkout, then 486 MB → 1 747 MB in the last ~5 s ending at the throw — the blow-up and the bad parse are one event (suspect: a corrupt record size → io.buf(size*4+256) giant alloc → garbled resolve → git.tree refuses).
• Locus to start from: be/shared/store.js getObject/readTree resolve path (the Buf sizing off pk.size), the JABC pack cursor state (pk.seek/resolve reuse across ~10^5 calls), and jab cont.cpp _pack_next/_pack_size — note JAB-007's Buf | 0 int32 cursors: offsets/watermarks past 2^31 are NOT in play here (log is 698 MB), but the same narrowing pattern in per-record math is a candidate.
• Fixture recipe (cheap to rebuild, no re-download): git clone --mirror https://github.com/torvalds/linux.git ONCE, then git clone --bare --single-branch --branch v3.0 <mirror> medium.git; git -C medium.git update-ref refs/heads/master 02f8c6aee8df…; git -C medium.git symbolic-ref HEAD refs/heads/master.

Goals

• The medium (v3.0) clone completes: full checkout, jab status sane, no anon blow-up.
• A bounded repro cheaper than 2 M objects if possible (bisect the object count / find the poisoning call pattern).
• Then the full linux gate (GET-044 + JAB-007) has no remaining JS-side wall.

Constraints

• Repro-first per work; do NOT paper over with a retry — find the poisoned state.
• GET-044's streaming + JAB-007's mmap fix are prerequisites for the FULL linux run but NOT for this repro (698 MB is under every cap).

WIP

• (open)

Outcome

• (open)