Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,773 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, sqlite
Lĩnh vực
backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
C
Star
45.8k
Fork
3.8k
Merge trung bình
3 ngày 4 giờ
Pull request đã merge (30 ngày)
208

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DeusData/codebase-memory-mcp

Tất cả issue của DeusData/codebase-memory-mcp

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.