ts_runtime: bound GLR stack-merge recursion to prevent stack overflow on pathological input

[halindrome]

Split out of #461 at maintainer request: patches to the vendored tree-sitter runtime (internal/cbm/vendored/ts_runtime/) warrant a separate decision from ordinary language-extraction code, so filing this independently.

Problem

The GLR stack-merge in internal/cbm/vendored/ts_runtime/src/stack.c recurses without a depth bound. On deeply / pathologically nested input the recursive merge can overflow the native stack — most likely on Windows, where the default thread stack is smallest.

Proposed fix

Bound the GLR stack-merge recursion depth, degrading gracefully past the cap (bounded merge — no incorrect parse), plus a tests/test_stack_overflow.c regression that uses a fork harness to isolate the crash from the rest of the suite.

Prepared commits on halindrome/codebase-memory-mcp (branch perl-lsp-semantic-resolution, pre-cleanup history):

• 064a6130 — fix(ts-runtime): bound GLR stack merge recursion to prevent Windows stack overflow
• 560f70a1 — test(perl-lsp): use fork harness for deep-nesting test to avoid thread-local parser leak

Provenance

Self-contained depth guard in the vendored runtime; no upstream-grammar regeneration involved. Happy to open a PR against whatever branch / process you prefer for runtime patches.

[DeusData]

Thanks for splitting this out from the Perl PR. Triage: vendored runtime hardening bug, normal priority.

A tree-sitter runtime patch needs separate provenance and risk review, as noted earlier. The acceptable shape is a narrow recursion cap with graceful degradation plus a crash-isolating regression, with no unrelated runtime behavior changes.

[DeusData]

Yes please — open the PR against main. This is exactly the right split: vendored-runtime patches deserve their own review. Process notes for ts_runtime changes: (1) keep it reproduce-first — the fork-harness deep-nesting test should be RED (stack overflow contained via the harness) before the depth bound lands, so the guard provably catches the crash class; (2) document the local modification in the vendored runtime's provenance notes (same spirit as the grammar MANIFEST — we track every divergence from upstream so a future runtime upgrade doesn't silently drop it); (3) note the upstream tree-sitter issue/PR if one exists so we can retire the patch when upstreaming catches up. Milestone 0.9.1-rc. Looking forward to it — the bounded-merge degradation (no incorrect parse) is the right call.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.