Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,560 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
C
Estrellas
45.8k
Forks
3.8k
Merge medio
3 d 4 h
PR fusionados (30 d)
208

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DeusData/codebase-memory-mcp

Todos los issues de DeusData/codebase-memory-mcp

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.