Direct same-file calls to static functions produce zero CALLS edges (empty trace_path callees)
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 55/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- c, sqlite
- Ambito
- backend-api-design
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C
- Stelle
- 45.8k
- Fork
- 3.8k
- Merge medio
- 3g 14h
- PR unite (30g)
- 210
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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DeusData/codebase-memory-mcp
-
bug editor/integration stability/performance
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
DeusData/codebase-memory-mcp#2818 ·
I maintainer di solito rispondono entro 2 giorni
-
Generated Pi extension (cbmem.ts) breaks Gemini/Antigravity: Type.Union of Type.Literal serializes to anyOf/constForse già presa @divakantpandey l’ha presa 2 giorni fa. Apertabug editor/integration
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DeusData/codebase-memory-mcp#2787 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
editor/integration parsing/quality
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
DeusData/codebase-memory-mcp#2286 ·
I maintainer di solito rispondono entro 2 giorni
-
install writes an unsupported `args` key into the Claude Code SubagentStart hook, so it never runsApertabug editor/integration priority/high stability/performance ux/behavior
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DeusData/codebase-memory-mcp#2239 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
bug priority/high ux/behavior
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DeusData/codebase-memory-mcp#2232 · 2 commenti ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di DeusData/codebase-memory-mcp
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
ly05010419/MacNativeGames#1252 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 2 giorni
-
Component - Build
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Description of the bugApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
HarbourMasters/Lighthouse#655 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100