Repository navigation
Dump-phase crash on large TS monorepo (v0.6.1, darwin-arm64) — pipeline completes through semantic_edges then terminates abnormally before gbuf.dump #317
Description
Summary
codebase-memory-mcp v0.6.1 reliably crashes during the dump phase when indexing a large TypeScript monorepo on macOS arm64. The pipeline completes 12 passes — including parallel_extract, parallel_resolve, similarity, semantic_edges — and then terminates abnormally before gbuf.dump ever fires. No DB is persisted. Three runs reproduce deterministically across two different input sizes.
This appears to be the same dump-phase crash reported in #189 (large Java project, v0.5.7) but on a different platform/language combination, on the current release. Distinct from #141, which crashes earlier in parallel_extract.
Environment
| Version | codebase-memory-mcp 0.6.1 (latest release, prebuilt darwin-arm64 binary, SHA-256 verified against checksums.txt) |
| OS | macOS arm64, ample free RAM (32 GB total system, indexer hits ~5.5 GB peak) |
| Repo | a large internal TypeScript monorepo |
Internal mem budget on startup: level=info msg=mem.init budget_mb=16384 total_ram_mb=32768 — peak RSS observed during the run is well under that 16 GB budget.
Reproduction
Two inputs, two scale points, same crash:
| Input | Files | Result |
|---|---|---|
| Full monorepo | ~138 K TS/TSX + 16 K .py | crash |
harbor/ workspace subset only |
~107 K TS/TSX + 16 K .py | crash |
| Single package within the monorepo (~2,540 TS files) | small | succeeds — full pipeline + DB persisted |
Command:
codebase-memory-mcp cli index_repository '{"repo_path":"/path/to/large/ts-monorepo","name":"my-monorepo"}'
Pass-by-pass timeline (harbor run)
pass=structure 75 ms
pass=parallel_extract 16,577 ms (742,694 nodes extracted, 206 errors)
pass=registry_build 1,008 ms
pass=parallel_resolve 11,088 ms
pass=k8s 71 ms
pass=tests 290 ms
pass=githistory_compute 2,546 ms
pass=decorator_tags 38 ms
pass=configlink 962 ms
pass=route_match 134 ms
pass=similarity 190 ms (28,112 fingerprints → 21,253 SIMILAR_TO edges)
pass=semantic_edges 6,960 ms (81,503 functions, vectors stored, LSH built, 14 edges)
<<< CRASH HERE >>>
no `pass.start pass=dump` line
no `gbuf.dump nodes=X edges=Y` line
no `pipeline.done` line
time: command terminated abnormally
65 s real, 5.5 GB peak RSS
Same crash signature on the full-monorepo run: dies after pass=semantic_edges completes (elapsed_ms=4894), before dump. 39 s real, 5.2 GB peak RSS.
Diagnostic notes
- Reproducible across two distinct repo subsets, so it's not corrupt input on one specific file.
- Single mid-size package indexes cleanly through
gbuf.dumpandpipeline.done, so the issue isn't in the dump code path's correctness — it's a scale threshold somewhere between ~30 K and ~80 K functions, or between ~57 K and ~? edges (the larger run never reaches the edge-count totals becausegbuf.dumpis where those get computed). - Peak RSS ~5-5.5 GB, well under the 16 GB internal budget and the 32 GB system RAM. So it's not classic OS-level OOM.
time: command terminated abnormallywith0 signals receivedin the wrapper output — process exits via something the shell doesn't classify as a signal. Suggests an internal abort/assert/explicit exit rather than SIGKILL from the OS.- 200+ extraction errors during
parallel_extractare logged but explicitly handled (level=infonot error) and the pipeline continues normally, so they're not load-bearing on this crash.
Related issues
- Crash on Large Java Project: Memory Corruption Causes Database Corruption #189 — "Crash on Large Java Project: Memory Corruption Causes Database Corruption" — same dump-phase crash, macOS arm64, v0.5.7, results in DB corruption with SIGTRAP / pointer authentication failure. Same code path; bug appears to persist into v0.6.1.
- Full-repo indexing crashes in parallel.extract on large AOSP-scale repository #141 — "Full-repo indexing crashes in parallel.extract on large AOSP-scale repository" — distinct (crashes much earlier, in
parallel_extract).
Hypothesis
The dump-phase write of ~80 K function semantic vectors + similarity/CALLS/IMPORTS edges into the in-memory SQLite (level=info msg=gbuf.dump) is the most likely failure surface. Given #189's pointer-auth trap signature on the same code path and the consistent ~5 GB RSS at crash, my guess is a memory-corruption bug in the buffer-management between pass=semantic_edges and the SQLite dump (perhaps a buffer reuse / lifetime issue that only manifests once a particular buffer is large enough).
Useful for triage
Happy to share any additional logs (verbose flag if available, partial cmm.db file from a crashed run, or run with specific instrumentation). I have a clean macOS arm64 + 32 GB RAM environment that reproduces this in 30-60 s, so quick to test fixes against.
In the meantime we're working around it by indexing per-package — every individual package indexes cleanly. Useful for our deployment scenario but loses cross-package call/import edges, so a fix would unlock real value.
Activity
DeusData commentedon May 30, 2026
Likely resolved by the v0.7.0 cross-LSP rewrite. This dump-phase abnormal-termination on a large TS monorepo is very likely the same heap-corruption class as #340/#344 (scale-dependent crashes in the old
lsp_crosspass) — those are fixed in v0.7.0, which fuses cross-file LSP into the arena-based parallel resolver and removes the fixed-size def-array assumptions. The cgroup-aware worker sizing (#363) and WAL-checkpoint-on-close (#277) fixes also reduce memory pressure / corruption at the dump phase.Could you retest on v0.7.0 / current main? If it still terminates before
gbuf.dump, please reopen with the repo (or a stack/core), and I'll build a targeted repro. 🙏DeusData commentedon May 31, 2026
Thanks for the detailed pass-by-pass breakdown — "completes ~12 passes then terminates before
gbuf.dump" on a large TS monorepo is the scale-dependent crash class that got significant hardening for v0.7.0: #340 (segfault at lsp_cross start on 200+-file repos), #344 (SIGSEGV when all_defs exceeds ~1189 entries), plus 82d5c84 (lsp_cross thread-parser/slab ordering) and #339 (converted remaining fixed-size stacks to dynamic allocation).Could you retest the monorepo on v0.7.0 (darwin-arm64)? If it still crashes before dump, the index log up to the crash (and the repo's rough file/LOC count) would help me localize whether it's still lsp_cross or genuinely the dump path. Keeping open pending your v0.7.0 result. Thanks!
airowe commentedon Jun 11, 2026
Possibly useful data point for the v0.7.0 retest list: we hit what looks like this issue's profile on a large private healthcare monorepo (mixed Ruby + TypeScript, ~22k tracked files / ~20k indexed, ~39.3k functions at the semantic pass).
On a teammate's install (predates the v0.7.0 fixes; has the semantic pass so 0.6.1):
i.e.
semantic_edgescompletes and it dies entering the next pass — which by v0.7.0's pass order isdump.Same repo on v0.7.0 (macOS arm64, 24GB RAM, budget_mb=12288), near-identical input (39,263 functions — within 0.17%): full cold index completes cleanly, including
dump(876ms) andpersist_hashes— 153,055 nodes / 334,637 edges in ~15s total.So for this codebase shape v0.7.0 looks fixed. We're upgrading the affected machine and will report back with the .ips crash report if it still reproduces on a verified 0.7.0.
DeusData commentedon Jun 12, 2026
v0.8.1 is out and carries further hardening beyond the v0.7.0 fixes discussed above, including a large memory-safety and extraction-regression pass.
@hjdesai2 could you retest the monorepo on v0.8.1? Same ask as before: if it still terminates before
gbuf.dump, the last ~20 log lines would localize it.@airowe thanks for the data point — note your teammate's trace is from 0.6.1, which predates all of the lsp_cross/dump-phase fixes. A run of the same healthcare monorepo on v0.8.1 would be a really valuable signal either way (22k files / 39k functions is exactly the scale these fixes target).
DeusData commentedon Jun 26, 2026
Hey @hjdesai2, thanks again for the original detailed report — this is still open and
we're actively working to lock it down with a regression test.
Could you do a quick retest on v0.8.1? The 0.8.x cycle added a second round of
memory-safety hardening in the dump and persist phases, targeting exactly the post-
semantic crash class you hit.
Instructions for your coding agent:
If it still crashes: the last ~30 log lines plus the exit code are enough for us to
localize the remaining bug. If it now completes cleanly, a one-line confirmation would
let us close this with confidence.
Thank you for your patience!
ralf003 commentedon Jul 8, 2026
v0.8.1 retest -- still reproduces on Windows x64 + large TS monorepo
Reproduction requested by maintainer in the 2026-06-12 update of this issue.
Environment:
Repository tested:
Reproduction (2/2 attempts, 100% reproducible):
Crash signature (both runs identical):
Last stderr lines before crash:
Notably,
parallel.extract.donereports 501,847 nodes but the subsequent pass only carries 22,179 -- and the crash follows the timing report of the final pass before gbuf.dump would normally log.For comparison -- smaller repos index fine:
Artifact:
Root cause hypothesis (non-maintainer speculation):
The large delta between extracted nodes (501K) and final-pass nodes (22K) suggests heavy deduplication or filtering between extraction and the final graph pass. If the deduplication structures or intermediate buffers are not correctly sized for the unfiltered node count, the gbuf.dump write could be addressing out-of-bounds memory.
This matches the original v0.6.1 darwin-arm64 report: pipeline completes through semantic_edges then terminates abnormally before gbuf.dump. The bug persists in v0.8.1 on Windows x64 with large TS monorepos.
Let me know if you need a minidump or any other diagnostic data. Also happy to test a patched build.
DeusData commentedon Jul 14, 2026
Thanks for the detailed large-monorepo reproduction. I have removed awaiting-reporter and returned this to the maintainer-owned 0.9.1-rc stability queue. The Windows v0.8.1 result is sufficient evidence that the scale-dependent termination remained after the earlier hardening; the next step is to localize the final completed pass and reproduce the process exit without losing the worker log.
hjdesai2 commentedon Sep 21, 2026
Re-tested on v0.11.0 and I can no longer reproduce the dump-phase crash — the pipeline completes and a DB is persisted.
Result
semantic_edges, beforegbuf.dumpSame platform (macOS arm64, 32 GB), same monorepo, same invocation:
Result payload:
nodes == expected_nodesandedges == expected_edges, so the dump wrote everything it intended rather than truncating — which is the part the old crash skipped entirely. The DB is also queryable afterwards;search_graphreturns correct paths and line numbers against it.Two caveats on how strong this evidence is
parallel_extract, whereas 404,891 above is nodes persisted after resolution. Those are different metrics, so this isn't an exact scale match — I can't claim the run was equally large, only that it was the same repo on the same platform and got past the failing phase.Happy for this to be closed if it matches a known fix. If it'd help pin down which change fixed it, I'm glad to bisect across the releases between v0.6.1 and v0.11.0 — though note v0.6.1 itself is no longer downloadable (the release appears to have been deleted; its asset URL now 404s), which is worth knowing independently since it silently broke pinned builds.
DeusData commentedon Sep 25, 2026
Thank you so much for coming back after all these months, and for such a careful retest.
nodes == expected_nodesandedges == expected_edgeson v0.11.0 is exactly the proof we needed that the dump now completes and writes everything. The lsp_cross rewrite and the memory work since then removed that crash class, so no bisect is needed. Thanks also for flagging that the v0.6.1 release assets now return 404; we've noted that separately. Closing as fixed. Please reopen anytime if it comes back!