False Negative: DoubleCheckedLockingWithInitRace.ql misses initialization races once the double-checked pattern is split across helpers or early returns.

Bắt đầu bằng cách đọc Likely Bugs/Concurrency/DoubleCheckedLockingWithInitRace.ql cùng các ví dụ PosCase1_Var3.java và PosCase1_Var5.java. Theo dõi cách truy vấn xử lý các lệnh gọi helper và các lần trả về sớm, sau đó xác minh rằng cả hai biến thể race khi khởi tạo đều được đánh dấu.

False Negative: DoubleCheckedLockingWithInitRace.ql misses initialization races once the double-checked pattern is split across helpers or early returns.

Version
codeql 2.24.3

Checker

• Checker id: Likely Bugs/Concurrency/DoubleCheckedLockingWithInitRace.ql
• Checker description: This checker detects a potential race condition in double-checked locking patterns where a field assignment inside a synchronized block may be visible to other threads before subsequent side-effect statements are executed.

Description of the false negative

These samples still publish f before the rest of the initialization work is complete. One variant moves the synchronized initialization into a helper, and the other rewrites the fast path as an early return, but the initialization race is the same.

Affected test cases

PosCase1_Var3.java

The helper call only hides the same double-checked-locking race where publication happens before later side effects.

// Double-checked locking with assignment to another field after the field assignment should be flagged as potential race condition.
package scensct.var.pos;

public class PosCase1_Var3 {
    private Object f;
    private Object otherField;

    public Object getF() {
        if (f == null) {
            initField();
        }
        return f;
    }

    private void initField() {
        synchronized (this) {
            if (f == null) {
                f = new Object();
                otherField = new Object();
            }
        }
    }
}

PosCase1_Var5.java

This still publishes the initialized object before a later field assignment completes, which is the race the query is meant to catch.

// Double-checked locking with assignment to another field after the field assignment should be flagged as potential race condition.
package scensct.var.pos;

public class PosCase1_Var5 {
    private Object f;
    private Object otherField;

    public Object getF() {
        if (f != null) {
            return f;
        }
        synchronized (this) {
            if (f == null) {
                f = new Object();
                otherField = new Object();
            }
            return f;
        }
    }
}

Cause analysis

The query appears too tied to one inline statement ordering pattern for double-checked initialization. Once the synchronized block is extracted into a helper or the fast path is expressed as an early return, it stops recognizing that f becomes visible before the remaining side effects complete.

That is a real concurrency gap. Initialization races often survive exactly this kind of refactoring.

References

None known.