Summary
v0.8.1 — the latest release, and what codebase-memory-mcp update and the install script distribute today — ships octree_insert without the depth/half-size recursion guard. Coincident node positions make the 3D layout subdivide without bound, one calloc'd cell per level, until the OS kills the process. Main has the fix since July 4 (2b12f00, "fix(ui): bound octree recursion for coincident points"), but no release carries it.
Please cut a patch release. Every current user with a mid-size repository who clicks "View Graph" is one click away from the failure below.
Real-world impact (measured, macOS 15 / M4 Max / 36GB)
Repository: 155,123 nodes / 222,680 edges (PHP/Vue monolith). Coincident positions are guaranteed at this shape: ~120k Variable nodes share a handful of directory-cluster anchors, and jitter is quantized (5/4096 quanta from a 32768-value PRNG grid), so exact collisions are a birthday-paradox certainty. Your own layout_octree_guard_child test comment documents the mechanism ("the 34GB-swap reports").
With CBM_DIAGNOSTICS=1 on the stock v0.8.1 binary:
/api/layout?max_nodes=50000 (the UI's default request): peak_rss_bytes: 18,910,167,040 (17.6GB) before dying at ~110s.
- A later attempt reached 156GB of memory footprint in Activity Monitor before we killed it.
- Death is a memorystatus SIGKILL (verified under lldb:
stop reason = signal SIGKILL) — silent, no crash report, no log line, which makes it look like a mystery hang/disappearance to users.
- Practical survival threshold on a loaded machine was ~12-15k nodes; anything above was roulette.
Secondary symptom observed on v0.8.1: after a failed layout request the embedded HTTP listener sometimes stopped accepting connections while the process stayed alive (instant connection-refused on all endpoints until restart). Likely moot once the layout no longer fails, but noting it in case it is a separate fd bug.
Confirmation that main is fixed
Built main (--with-ui) and measured the same repository: full 155,123-node layout completes in 16.8s at a flat 245MB RSS (instrumented: ~250k octree cells/iteration, depth ≤ 23, stable across all 40 iterations). Night and day — the fix works. It just needs a release.
Related: #916 fixes the generated .gitattributes ordering (merge=ours binary → binary merge=ours), found during the same investigation.
Summary
v0.8.1 — the latest release, and what
codebase-memory-mcp updateand the install script distribute today — shipsoctree_insertwithout the depth/half-size recursion guard. Coincident node positions make the 3D layout subdivide without bound, one calloc'd cell per level, until the OS kills the process. Main has the fix since July 4 (2b12f00, "fix(ui): bound octree recursion for coincident points"), but no release carries it.Please cut a patch release. Every current user with a mid-size repository who clicks "View Graph" is one click away from the failure below.
Real-world impact (measured, macOS 15 / M4 Max / 36GB)
Repository: 155,123 nodes / 222,680 edges (PHP/Vue monolith). Coincident positions are guaranteed at this shape: ~120k Variable nodes share a handful of directory-cluster anchors, and jitter is quantized (5/4096 quanta from a 32768-value PRNG grid), so exact collisions are a birthday-paradox certainty. Your own
layout_octree_guard_childtest comment documents the mechanism ("the 34GB-swap reports").With
CBM_DIAGNOSTICS=1on the stock v0.8.1 binary:/api/layout?max_nodes=50000(the UI's default request):peak_rss_bytes: 18,910,167,040(17.6GB) before dying at ~110s.stop reason = signal SIGKILL) — silent, no crash report, no log line, which makes it look like a mystery hang/disappearance to users.Secondary symptom observed on v0.8.1: after a failed layout request the embedded HTTP listener sometimes stopped accepting connections while the process stayed alive (instant connection-refused on all endpoints until restart). Likely moot once the layout no longer fails, but noting it in case it is a separate fd bug.
Confirmation that main is fixed
Built
main(--with-ui) and measured the same repository: full 155,123-node layout completes in 16.8s at a flat 245MB RSS (instrumented: ~250k octree cells/iteration, depth ≤ 23, stable across all 40 iterations). Night and day — the fix works. It just needs a release.Related: #916 fixes the generated
.gitattributesordering (merge=ours binary→binary merge=ours), found during the same investigation.