Beagle SCM

JAB-007 JS: Buf cursor | 0 int32 coercion caps every mapped view at 2^31-1 — io.mmap of a >2GB file returns a silently WRONG view, git.pack.mmap ABORTS on multi-GB keeper logs

jab's JS Buf class (the buf.cpp prelude) coerces its _data/_idle cursors with | 0 (signed int32). io.mmap wraps every file mapping in Buf.over(u8) which seeds _idle = u8.length | 0 — for any file ≥ 2 GiB that wraps NEGATIVE, and .data()'s subarray(0, _idle) then reinterprets the negative end END-RELATIVE, silently returning a short/garbled view (no throw). git.pack.mmap rides the same wrapper, so scanning a multi-GB keeper log feeds nonsense windows to the native pack scanner and the (ASAN) process ABORTS. This is the wall that blocks GET-044's linux-scale clone AFTER the streamed pack lands: a 6.4 GB 0000000001.keeper is durable on disk but can be neither indexed nor read. The C and JSC layers are NOT at fault (verified — see Context). Method: work.

Input

Context

• Probed 2026-07-14 on the deployed jab (Jul 12 build, libjavascriptcoregtk-4.1):
  • io._mmap("3GB-file","r").length → *3000000000 CORRECT* (C + JSC handle big lengths fine);
  • io._ram(3000000000).length → 3000000000 CORRECT (same JSObjectMakeTypedArrayWithBytesNoCopy path);
  • new Uint8Array(3000000000) heap → CORRECT;
  • io.mmap("3GB-file","r").data().length → *1705032704 WRONG* = 3e9 + (3e9|0) — the Buf wrap;
  • boundary exact: size 2147483647 → correct; 2147483648 → length 0; above → 2*(size mod 2^31).
• Root cause (jab/buf.cpp JS prelude, Buf constructor):

  this._data = data | 0; this._idle = (idle === undefined ? data : idle) | 0;

  Buf.over(u8) passes idle = u8.length; 3e9 | 0 = -1294967296; subarray(0, negative) counts from the END → the observed 1705032704. At exactly 2^31 the negative end lands on 0 → empty view.
• git.pack.mmap on a >2^31-1 file: native ABORT (ASAN) — reproduced with a sparse 3 GB file, git.pack.mmap(path, "r") → Aborted (the pack scan walks a garbled window).
• Live impact: GET-044 now streams a linux clone's 6.4 GB pack to the shard with ~14 MB heap and lands it verified; ingest.buildIndex/store.open then CANNOT read the log — be/shared/ingest.js ships an MMAP_CAP = 2147483647 guard that refuses cleanly instead of crashing (ingest: … landed OK but exceeds the jab 2^31-1 mmap cap). Every multi-GB repo clone stays blocked until this lands.
• Fix sketch: drop the | 0 on the cursor fields (JS doubles are exact to 2^53; the cursors only ever hold byte offsets), audit the other | 0/int narrowings in the Buf prelude + cont.cpp watermark plumbing, and add a >2GB sparse-file regression (map, .data().length, pack.mmap scan) to jab's tests.

Goals

• io.mmap of a >2GB file yields a full-length, correct .data() view; git.pack.mmap + pack.scan work on a multi-GB keeper log (no abort).
• A regression test pins the 2^31 boundary (sparse files are cheap — no big fixture needed).
• be/ side: once landed, drop the GET-044 MMAP_CAP refuse (or raise it to the real engine bound) so linux-scale index/checkout proceeds.

Constraints

• jab repo (~/src/jab), not be/; the be/-side guard lands with GET-044 and stays until this ships.
• Watch the JSC ArrayBuffer cap separately: heap Uint8Array(3e9) works, but the engine's true max should be probed and documented while at it (the GET-044 RangeError at ~2.7 GB concat suggests a lower ceiling for some alloc paths).

WIP

TODOs

• Drop | 0 on Buf _data/_idle (+ audit size/room/feed/take arithmetic for other 32-bit narrowings).
• Audit cont.cpp buffer.watermark plumbing for the same narrowing.
• Sparse-file regression: 2^31-1 / 2^31 / 3e9 map lengths + a pack.mmap scan over a >2GB synthetic log.
• Then GET-044 follow-up: lift the be/ MMAP_CAP guard, rerun the linux gate end-to-end.

Outcome

• (open)