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

Start with Likely Bugs/Termination/ConstantLoopCondition.ql and inspect how its existing tests cover constant loop conditions. Reproduce the misses in PosCase1_Var5.java, PosCase2_Var4.java, and PosCase5_Var5.java, then run the relevant query tests. Done means all three helper-wrapped or guarded non-terminating loops are detected without losing existing coverage.

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.