Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Index worker spins on a large pg_dump .sql with escaped apostrophes

Aperta
  • Qualcosa non va?
#2,560 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
backend

Direzione di ricerca

Start by tracing the index worker’s handling of large SQL files and how it processes SQL-escaped apostrophes; the report does not name source files or tests. Try reproducing with a synthetic INSERT INTO ... VALUES file containing cumulative don''t strings, since the original file is private. Done means the worker indexes the file or fails promptly instead of spinning and consuming excessive memory.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

stability/performance windows
Version

codebase-memory-mcp 0.11.0

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1 (via mise's github: backend)

Binary variant

standard

What happened, and what did you expect?

I've been running index_repository across ~125 repos, and one of them never finished. I tracked it down to a single 34MB .sql file (a pg_dump fixture). With that file in the repo, the index worker pegs one core (~95% CPU, RSS around 1.6GB), prints no progress, and writes nothing. Excluding just that file, the repo indexes in 83s, including 55 other .sql files up to 2.7MB.

The hang supervisor from #827 does eventually catch it, but with the defaults that takes ~30 minutes (the 15 minute no-progress timeout, then the single-threaded recovery re-run). My per-repo caps were shorter than that, so I never saw it. With CBM_INDEX_WORKER_TIMEOUT_S=20 set on the daemon, the file gets "quarantined after hang" in about 80s, and later runs skip it.

I'd expect the file to index (or at least fail fast). The bug is whatever the worker is spinning on.

Reproduction

I can't share the file (private data), and I haven't managed a synthetic repro yet, so here's what I've narrowed it to:

  • The file is one INSERT INTO ... VALUES statement spanning ~9.2k lines, with a rich-text JSON document as a string literal in each row.
  • It reproduces with the file alone in an empty git repo: codebase-memory-mcp cli --progress index_repository --repo-path <dir>
  • The words don't matter. Replacing every letter with x and every digit with 0 still hangs.
  • SQL-escaped apostrophes inside words (don''t) are necessary. Replacing just those (~1,100 in 13.5MB) makes it index in 12s. Removing other escapes (\", \n), HTML attribute quotes (href=''...''), URLs, or empty strings changes nothing.
  • It's cumulative. Each quarter of the slow rows indexes in 7-9s on its own, but together they take 34s, and a 13.5MB prefix spins indefinitely.
  • Simple generators don't trigger it: one it''s per row at 2-16MB, or random text with apostrophes at the same rate plus \", \n, and HTML, all index in under 10s. So something else about the real structure combines with the ''.
Logs

The binary's stripped, but sample puts nearly all CPU in one tight loop around +0x105a760 to +0x105aa58 from the load address. CBM_INDEX_SINGLE_THREAD, CBM_LSP_DISABLED, CBM_DISABLE_LSP_CROSS, CBM_SEMANTIC_ENABLED=0, CBM_TS_TYPE_BUDGET, and CBM_WALK_DEFS_MAX don't change the timing. Happy to grab a CBM_DIAGNOSTICS=1 trajectory if that helps.

Confirmations
  • I searched existing issues and this is not a duplicate.
  • My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 4h
PR unite (30g)
208

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.