Repository navigation
TypeScript monorepo: index worker dies with SIGBUS — "Thread stack size exceeded due to excessive recursion" in the resolver pass (every package indexes alone; only the union crashes) #2349
Description
Summary
index_repository cannot index a large private TypeScript monorepo (12 GB on disk, 168,201 files, 32 workspace packages, Bun workspaces). Every attempt dies ~25 s in, in the cross-file resolution pass, with the index worker killed by SIGBUS. Every subset of the same repository indexes cleanly — only the union crashes.
Version: 0.11.0 (upgraded from 0.10.5 while investigating). macOS 27 (arm64), 24 GB RAM, 198 GB free disk.
What happens
$ codebase-memory-mcp cli --json index_repository --repo-path <repo> --mode full
index worker ended with crash (exit=-1, signal=10); inspect log: ~/.cache/codebase-memory-mcp/logs/.worker-log
Reproduces with --mode full and --mode fast, with --persistence true and false, and with CBM_MEM_BUDGET_MB=16384. (The 0.11.0 message here is a real improvement over 0.10.5, which surfaced this as a bare exit 1.)
It is a stack overflow, not a memory limit
From the macOS crash report (~/Library/Logs/DiagnosticReports/codebase-memory-mcp-*.ips):
exception: EXC_BAD_ACCESS (code 2) / SIGBUS
message: "Thread stack size exceeded due to excessive recursion"
faulting frames: a single frame repeated ~7× (offsets +21103280 … +21110592)
The worker's own log ends mid-pass:
msg=parallel.extract.done nodes=344473 errors=4
msg=parallel.registry.done entries=328376 defines=344473 imports=24711
msg=lsp_cross_prepare.builders go=0 python=1 c=1 cs=1 ts=7 java=77
msg=mem.phase phase=lsp_cross_prepare rss_mb=1182 footprint_mb=985 peak_mb=1182 peak_charged_mb=1068
msg=parallel.resolve.start files=4504 workers=12
<nothing after this line>
Memory is not the constraint: peak 1182 MB against an 8601 MB budget, and raising the budget changes nothing. Raising the shell stack (ulimit -s 65500) also changes nothing — consistent with the recursion being on a worker thread, whose stack the tool sets.
Bisection: every part indexes, the union does not
| Scope | Result |
|---|---|
biggest package, dist/ only (30 files) |
✅ 36,869 nodes (70 s) |
biggest package, src/ only (368 files) |
✅ 5,672 nodes (3 s) |
biggest package, test/ only (330 files) |
✅ 969 nodes (3 s) |
| each of all 32 packages, one at a time | ✅ every one passes (biggest: 13,447 nodes, 21 s) |
| whole repository (the union) | ❌ SIGBUS at parallel.resolve |
Two further data points:
- The biggest package on its own crashes. Adding a
.cbmignorecontainingtest/makes it pass (6,000 nodes) — so the test tree is a reliable trigger at package scope. - The whole-repo crash persists even with
test/excluded, so there is more than one contributor to the union case.
Why this is distinct from what is already open
- PHP: trait whose name collides with an aliased
use … asimport it composes → unbounded recursion indefinitionspass, OOM (SIGKILL) #765 is unbounded recursion in the PHPdefinitionspass, failing as OOM (SIGKILL). This is the TypeScript/JS resolver path, failing as a stack overflow (SIGBUS), and it makes a project impossible to index at all. - task: Stability — crashes, segfaults, and memory safety during indexing (14 issues) #390 (stability tracker) — happy for this to be linked there; it is another data point for the same family.
Two consequences worth fixing alongside
- A crash during the stale-format migration leaves the project unserved. After the failed run,
search_graphfor that project returns 0 results, while its index database (278 MB) is still on disk. It would help if a failed reindex left the previous index serving, or if the format stamp were only advanced after a successful pass. - Each crashed attempt leaves a 0-byte
<db>.stage.*.lockand a ~548 KB.worker-log-*behind.
Repro
# the failure
codebase-memory-mcp cli --json index_repository --repo-path <repo> --mode full
# the bisection that isolates it
codebase-memory-mcp cli --json index_repository --repo-path <repo>/packages/<pkg> --mode fast --persistence false # passes
Deterministic: always ~25 s in, at parallel.resolve.start. I can run any instrumentation or bisection you want (recursion counters, a depth cap, a larger worker stack), or test a build — and I can share the repository shape in more detail privately if useful. I would rather not paste the private source here.
Activity
Kensima2 commentedon Oct 8, 2026
Corroboration on Windows x64 — same failure class, plus a much smaller public repro.
Environment: codebase-memory-mcp 0.11.0 (npm channel), Windows 11 Pro Workstation (build 26200), amd64, 32 GB RAM.
Symptom matches exactly.
index_repositorydies in the cross-file resolution pass. The worker log's last line is alwaysand immediately after it the supervisor reaps the worker:
It is a stack overflow on Windows too. Re-running the same input 4/4 crashed, but the exit code drifts between four memory-fault statuses — the Windows face of the macOS
EXC_BAD_ACCESS/ "excessive recursion" you saw:0xC00000FD0xC00000050x800000010xC00004090xC00000FDis the literal stack-overflow status and matches your "Thread stack size exceeded due to excessive recursion". Memory is not the constraint here either: peak RSS ~1.0 GB againstbudget_mb=11246.Not a size threshold — and a small public repro. Repo =
anomalyco/opencode@ tagv2.0.24(8,576 files, 133 MB). Public, so no private source needed.packages/cli(200 files, 1,807 nodes) indexes fine — butpackages/server(89 files) crashes. So it is not the ~6,781-file union per se.packages/server/src(52 files = 16 top-level*.ts+handlers/32 +middleware/4):handlers/alone ✅,middleware/alone ✅, the 16 top-level files alone (no subdirs) ✅--mode fulland--mode fast.Extra note: for the union case the daemon's quarantine-and-retry (
daemon.index.file_quarantined ... attempt=N) runs through 25 attempts without ever completing, and the "culprit" file it names changes on every attempt — consistent with the faulting recursion frame drifting rather than a single offending file.Happy to run instrumentation / a depth cap / a larger worker-stack build on Windows if that helps.
phaedrus1992 commentedon Oct 16, 2026
FYI, another public data point, macOS 27.0.1 arm64.
On 0.11.0, indexing
anomalyco/opencodeat tagv2.0.31(22728d674, 3,452 files, Bun/TS monorepo) hit the same thing: worker dies right afterlsp_cross_prepare/parallel.resolve.start files=3452 workers=10,signal=10, and the.ipssaysThread stack size exceeded due to excessive recursion(EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE). Happened in bothfastandmoderate. Faulting thread had the same shape as the original report, one frame repeated (offset +21110592 x6) under another recursive one (+19529052 x6).On 0.12.0 the same clone indexes cleanly in both
fastandmoderate(44,444 nodes, 210,079 edges, status ready, no crash report). So it looks fixed at least for this size of repo; I haven't got anything near the 168k-file case from the original report to test against.DeusData commentedon Oct 19, 2026
Thank you all for the cross-platform evidence and public OpenCode cases. The latest report that the same clone succeeds on 0.12.0 is useful, but does not yet establish resolution of the original larger case or the Windows case. If you have a safe newer-version result for those environments, please share it; private source is not needed.