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

Direct same-file calls to static functions produce zero CALLS edges (empty trace_path callees)

Aperta
#2,773 3 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
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, sqlite

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

awaiting-reporter bug parsing/quality
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

  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.