False Negative: ConstantLoopCondition.ql misses loops whose exit condition stays constant after being wrapped in helpers.

Bắt đầu với Likely Bugs/Termination/ConstantLoopCondition.ql và kiểm tra cách các test hiện có bao phủ các điều kiện vòng lặp hằng. Tái hiện các trường hợp chưa được phát hiện trong PosCase1_Var5.java, PosCase2_Var4.java và PosCase5_Var5.java, sau đó chạy các query test liên quan. Hoàn tất khi cả ba vòng lặp không kết thúc được bọc trong helper hoặc được bảo vệ bằng guard đều được phát hiện mà không làm mất coverage hiện có.

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.