Parallel indexing can corrupt the heap in the Haskell scanner

[WarGloom]

Version

codebase-memory-mcp dev at 5e7d3eb

Platform

Linux x64, built from source, UI variant, GCC 16.1.1

What happened

Indexing a mixed-language repository with two or more workers aborts with glibc heap-metadata corruption. One worker completes. Parallel indexing should complete without changing worker count or disabling concurrency.

Reproduction

1. Check out oraios/serena at dd7eb6d72ae179aa940e50cd6276ec5646f306f8.
2. Build the production binary with scripts/build.sh --with-ui.
3. Run index_repository against that checkout with CBM_WORKERS=2.
4. The index worker aborts during extraction. The same corpus also reproduces with 4 and 20 workers.

Valgrind with the production O2 build reports the first invalid write in advance -> take_line -> newline_lookahead -> tree_sitter_haskell_external_scanner_scan. The write uses the old contents pointer immediately after realloc moved the Lookahead buffer. The pinned Haskell tree_sitter/array.h passes differently typed Array structs through Array(void) pointers, violating strict aliasing; Tree-sitter fixed this class upstream in tree-sitter/tree-sitter#5242.

Expected

The existing parallel worker count remains enabled and the repository indexes successfully.

Scale

10,138 nodes and roughly 50,800 edges in the isolated reproduction corpus.

Confirmations

• Searched existing issues; no duplicate found.
• Reproduction uses the public oraios/serena repository.

[DeusData]

Thanks for the precise optimized-build diagnosis. PR #1232 is a small, plausible fix that reuses the already-vendored alias-safe Tree-sitter array helper and introduces no new dependency or vendored code. It is held only on the reproduce-first gate: we still need a minimized optimized multi-worker Haskell regression that is RED on main and GREEN with the patch.