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

goroutineresourceleak: checkChannelLeak misses usage via function-call indirection (channel_usage_indirection_blind)

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#69,613 1 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 1 ngày

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

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
devtools

Hướng nghiên cứu

Đọc pkg/linters/goroutineresourceleak/goroutineresourceleak.go, tập trung vào checkChannelLeak và markChannelUsage, sau đó xem lại SAFE PATTERNS trong testdata/src/a/a.go quanh các dòng 259-318. Thêm trường hợp kiểm thử được mô tả cho lời gọi hàm trợ giúp và mở rộng quá trình quét việc sử dụng để một channel được truyền cho hàm trợ giúp không bị báo cáo là rò rỉ. Hoàn tất khi trường hợp mới chạy thành công và các trường hợp dương tính, âm tính hiện có được liệt kê vẫn giữ nguyên hành vi.

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

Mô tả

cookie sergo
Problem

pkg/linters/goroutineresourceleak/goroutineresourceleak.go checkChannelLeak (lines 149-171), backed by createdChannels and markChannelUsage (lines 173-236), only recognizes a channel as used inside a spawned goroutine via three direct AST shapes within the goroutine body itself: a SendStmt (ch <- v), a literal close(ch) call, or a unary receive (<-ch). There is no handling for a channel being passed as an argument to another function call, stored into a struct field or closure, or returned -- all common decomposition patterns where the real send/receive/close happens inside the callee rather than inline in the goroutine body.

This causes a false-positive channel leak report on perfectly safe code: a goroutine that creates a channel and immediately hands it off to a well-behaved helper function (for example go func() { ch := make(chan int); process(ch) }(), where process does the actual send/receive/close) has zero recognized usage events under the current scan, so it falls through every safe-pattern check in checkChannelLeak and gets flagged as a leak.

Evidence
  • goroutineresourceleak.go:159-160 -- channels := createdChannels(pass, body); markChannelUsage(pass, body, channels), both walk only the goroutine's own body via ast.Inspect (excluding FuncLit boundaries)
  • goroutineresourceleak.go:208-233 -- markChannelUsage checks only *ast.SendStmt, a close(...) CallExpr, and a token.ARROW UnaryExpr; no case handles a channel identifier appearing as a plain CallExpr argument, a composite literal field, or a return value
  • testdata/src/a/a.go:259-318 (SAFE PATTERNS section) has zero coverage for a channel passed to a helper function -- every existing safe case either uses one of the three recognized syntactic forms directly inline, or is a named-function goroutine (go doSomeWork()), which is explicitly out of scope for the whole check per the namedFunctionGoroutine comment
  • This is distinct from the already-filed paren_unwrap_gap (#68591) and adjacent_defer_assumption (#68945) issues on this same linter, which affect checkCancelLeak/checkMutexLeak rather than checkChannelLeak
Recommendation

Extend markChannelUsage to also treat a channel identifier appearing as a CallExpr argument (or in a composite literal / return statement) as a usage event, at least conservatively marking it as both sent-and-received to suppress the diagnostic -- a full call-graph analysis is out of scope for an AST-heuristic linter, but a channel handed to any opaque call should not be treated as provably unused.

Validation checklist
  • Add a testdata case: ch := make(chan int); process(ch) where process is an external/unanalyzed function -- should NOT be flagged
  • Confirm existing positive cases (channelWithoutUse, channelWithSend, channelWithReceive, channelWithUnbufferedSequentialSendAndReceive) still correctly flag
  • Confirm existing negative cases (channelWithClose, channelWithBufferedSendAndReceive) still correctly pass
Effort

Small -- one function (markChannelUsage) plus one new testdata fixture.

Pattern class: channel_usage_indirection_blind (new -- a resource-usage scan recognizing only a closed set of direct syntactic forms, with no awareness of usage via a function-call indirection).

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 211.8 AIC · ⌖ 0.49 AIC · ⊞ 5.3K · ◷

  • expires on Oct 23, 2026, 7:59 PM UTC-08:00
Ngôn ngữ chính
Go
Star
5.4k
Fork
584
Merge trung bình
3 giờ 16 phút
Pull request đã merge (30 ngày)
829

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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 github/gh-aw

Tất cả issue của github/gh-aw

Issue tương tự

Thêm issue về Go

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.