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

    awaiting-reporterWaiting on the reporter for info/repro; stale bot will warn then closebugSomething isn't workingpriority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.stability/performanceServer crashes, OOM, hangs, high CPU/memoryux/behaviorDisplay bugs, docs, adoption UX

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions