Direct same-file calls to static functions produce zero CALLS edges (empty trace_path callees)
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- c, sqlite
- Área
- backend-api-design
Línea de trabajo
Start by tracing how C call edges are resolved and how trace_path reads them; the issue names no source files or tests. Check the README’s handling of ambiguous targets, then reproduce with same-file static helpers whose names occur elsewhere in the repository. Done means those calls resolve to their local definitions and appear as CALLS edges in outbound trace_path results.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Version
codebase-memory-mcp 0.12.1
Platform
Linux (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
Direct same-file calls to static functions produce zero CALLS edges (empty trace_path callees) -its basic feature issue.
For a C function that makes direct, same-translation-unit calls to static helper functions, the indexer creates no CALLS edges. trace_path --direction outbound returns an empty callees list even though the source clearly contains the calls. Reproduced on both v0.9.x and v0.12.1.
Environment
cbm versions: 0.9.x and 0.12.1 (same result)
Host: Linux, --mode full --persistence true
Source evidence (calls are unambiguous in the body) :
int s3ip_sysfs_psu_drivers_register(struct s3ip_sysfs_psu_drivers_s *drv)
{
...
ret = psu_root_create(); // direct call
if (ret < 0) { ...; return ret; }
ret = psu_sub_create(); // direct call
if (ret < 0) { psu_root_remove(); ...; return ret; } // direct call
ret = psu_temp_create(); // direct call
if (ret < 0) { psu_sub_remove(); psu_root_remove(); ...; return ret; } // direct calls
...
}
The callees are static functions defined in the same file,:
static void psu_root_remove(void) { ... } // line 914
static void psu_sub_remove(void) { ... } // line 881
prd3://data/codebase/.local/bin# HOME=/data/codebase ./codebase-memory-mcp cli trace_path
--project 25.2.branch
--function-name " 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register"
--direction outbound --depth 1
level=info msg=mem.init budget_mb=192775 total_ram_mb=385550
{"function":" 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register","direction":"outbound","callees":[]}
prd3://data/codebase/.local/bin# HOME=/data/codebase ./codebase-memory-mcp cli trace_path --project 25.2.branch --function-name " 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register" --direction both --depth 1
level=info msg=mem.init budget_mb=192775 total_ram_mb=385550
{"function":"25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register","direction":"both","callees":[],"callers":[]}
Root cause (hypothesis)
Because each static helper name has multiple identical copies across the repo, the call resolver cannot prove a unique global target and drops the edge. Per the README, ambiguous targets are retained as USAGE — but here even USAGE-to-callee is absent, so the call is dropped entirely. The resolver appears to skip same-file (translation-unit) scoping: a static callee should resolve to the local definition in the same file before the global uniqueness check.
Suggested fix
For C/C++, resolve static (internal-linkage) calls against same-file definitions first, so a duplicated static name resolves to its local translation-unit target and emits a CALLS edge, instead of being dropped as ambiguous.
Impact
Any C file with static helpers whose names are duplicated elsewhere in the repo loses its intra-file call graph — trace_path, call-hierarchy, and impact analysis silently return empty results (false negatives), which is worse than an error because it looks like "no call
Reproduction
Environment
cbm versions: 0.9.x and 0.12.1 (same result)
Host: Linux, --mode full --persistence true
Source evidence (calls are unambiguous in the body) :
int s3ip_sysfs_psu_drivers_register(struct s3ip_sysfs_psu_drivers_s *drv)
{
...
ret = psu_root_create(); // direct call
if (ret < 0) { ...; return ret; }
ret = psu_sub_create(); // direct call
if (ret < 0) { psu_root_remove(); ...; return ret; } // direct call
ret = psu_temp_create(); // direct call
if (ret < 0) { psu_sub_remove(); psu_root_remove(); ...; return ret; } // direct calls
...
}
The callees are static functions defined in the same file,:
static void psu_root_remove(void) { ... } // line 914
static void psu_sub_remove(void) { ... } // line 881
prd3://data/codebase/.local/bin# HOME=/data/codebase ./codebase-memory-mcp cli trace_path
--project 25.2.branch
--function-name " 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register"
--direction outbound --depth 1
level=info msg=mem.init budget_mb=192775 total_ram_mb=385550
{"function":" 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register","direction":"outbound","callees":[]}
prd3://data/codebase/.local/bin# HOME=/data/codebase ./codebase-memory-mcp cli trace_path --project 25.2.branch --function-name " 25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register" --direction both --depth 1
level=info msg=mem.init budget_mb=192775 total_ram_mb=385550
{"function":"25.2.branch.platform.s3ip-sysfs.s3ip_sysfs_frame.psu_sysfs.s3ip_sysfs_psu_drivers_register","direction":"both","callees":[],"callers":[]}
Logs
Diagnostics trajectory (memory / performance / leak issues)
Project scale (if relevant)
No response
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de DeusData/codebase-memory-mcp
-
bug editor/integration
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DeusData/codebase-memory-mcp#2787 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
editor/integration parsing/quality
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
DeusData/codebase-memory-mcp#2286 ·
Los mantenedores suelen responder en 2 días
-
install writes an unsupported `args` key into the Claude Code SubagentStart hook, so it never runsAbiertobug editor/integration priority/high stability/performance ux/behavior
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DeusData/codebase-memory-mcp#2239 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
bug priority/high ux/behavior
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DeusData/codebase-memory-mcp#2232 · 2 comentarios ·
Los mantenedores suelen responder en 2 días
-
documentation editor/integration parsing/quality priority/normal
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
DeusData/codebase-memory-mcp#2169 ·
Los mantenedores suelen responder en 2 días
Todos los issues de DeusData/codebase-memory-mcp
Issues similares
-
dependency component: oneMKL module: dpclang
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
intel/torch-xpu-ops#5880 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
CVE-2026-111497Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
fink/fink-distributions#1322 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 83/100
openvehicles/Open-Vehicle-Monitoring-System-3#1563 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100