Skip to content

v0.8.1 layout: unbounded octree recursion (17.6GB at 50k nodes, 156GB observed) — fixed on main since 2b12f00, please release #917

Description

@alex-plosceac

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 binarybinary merge=ours), found during the same investigation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions