False Negative: ConstantLoopCondition.ql misses loops whose exit condition stays constant after being wrapped in helpers.
還沒有人認領這個 Issue。
評估
研究方向
從 Likely Bugs/Termination/ConstantLoopCondition.ql 開始,檢查現有測試如何涵蓋常數迴圈條件。在 PosCase1_Var5.java、PosCase2_Var4.java 和 PosCase5_Var5.java 中重現未偵測到的情況,然後執行相關的查詢測試。完成的標準是:偵測出全部三個由 helper 包裝或由 guard 保護的非終止迴圈,同時不遺失現有涵蓋率。
由索引模型根據 Issue 內容生成。
描述
Version
codeql 2.24.3
Checker
- Checker id:
Likely Bugs/Termination/ConstantLoopCondition.ql - Checker description: This checker detects loop conditions that are constant within the loop body, potentially leading to non-terminating loops.
Description of the false negative
These loops are still non-terminating for the same reason as the direct patterns: the value that controls exit never changes inside the loop. The code only wraps that check in a helper or rewrites the exit test into an equivalent form.
That should not move the sample outside the scope of Likely Bugs/Termination/ConstantLoopCondition.ql.
Affected test cases
PosCase1_Var5.java
x is never updated, so check(x) never changes. The helper only obscures an otherwise obvious infinite loop.
// while loop with condition variable defined outside and no updates in body should be flagged as infinite loop
package scensct.var.pos;
public class PosCase1_Var5 {
private static boolean check(int val) {
return val > 0;
}
public static void main(String[] args) {
int x = 5;
// condition via helper method, x not updated
while (check(x)) {
System.out.println("stuck via method");
}
}
}
PosCase2_Var4.java
conditionHolds(y) is stable because y is never modified in the loop body. This is still a constant loop condition.
// while loop with condition using final field and variable defined outside should be flagged as infinite loop
package scensct.var.pos;
public class PosCase2_Var4 {
private static final int LIMIT = 10;
public static void main(String[] args) {
int y = 3;
// Extract condition evaluation to a helper method
while (conditionHolds(y)) {
System.out.println("stuck");
}
}
private static boolean conditionHolds(int val) {
return val < LIMIT;
}
}
PosCase5_Var5.java
The loop exit is written as a guarded return, but counter never changes, so shouldExit(counter) remains false forever and the loop still does not terminate.
// while true loop with if condition using variable defined outside controlling all exits should be flagged as infinite loop
package scensct.var.pos;
public class PosCase5_Var5 {
// Helper method to compute constant condition
private static boolean shouldExit(int c) {
return c == 1;
}
public static void main(String[] args) {
int counter = 0;
while (true) {
// Exit condition hidden in method call
if (shouldExit(counter)) {
return;
}
System.out.println("stuck");
}
}
}
Cause analysis
The misses point to a query that is matching specific loop syntax rather than the underlying stability of the condition. Once the condition is computed in a helper or turned into an equivalent exit guard, the analysis seems to stop following it.
That leaves a real blind spot. Developers often factor loop predicates into helpers, and those helpers do not make a non-terminating loop any safer.
References
None known.
- 主要語言
- CodeQL
- 星號
- 10.1k
- 分支
- 2.1k
- 平均合併
- 2 天 16 小時
- 30 天內合併 PR
- 143
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
github/codeql 的其他 Issue
-
agentic-workflows
難度 2/5 1-3 小時 新手友好度 70/100
-
false-positive javascript
難度 2/5 1-3 小時 新手友好度 84/100
-
難度 2/5 1-3 小時 新手友好度 82/100
-
難度 2/5 1-3 小時 新手友好度 78/100
-
false-positive
難度 2/5 1-3 小時 新手友好度 70/100
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 75/100
palladius/rails8-app-on-gcp#145 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
elastic/gradle-plugins#156 ·
-
area:workflow bug ready-for-agent
難度 2/5 1-3 小時 新手友好度 75/100
fil-donadoni/tolaria#4409 ·
-
難度 2/5 1-3 小時 新手友好度 65/100
dotenvx/dotenv-vscode#139 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
Fission-AI/OpenSpec#1960 ·