mirror of
https://github.com/github/codeql.git
synced 2025-12-17 17:23:36 +01:00
096d5f2a56
Our monitor analysis would be fooled by cycles in the call graph, since it required all edges on a path to a conflicting access to be either - targetting a method where the access is monitored (recursively) or - monitored locally, that is the call is monitored in the calling method For access to be monitored (first case) all outgoing edges (towards an access) need to satisfy this property. For a loop, that is too strong, only edges out of the loop actually need to be protected. This led to FPs.
33 lines
703 B
Java
33 lines
703 B
Java
package examples;
|
|
|
|
import java.util.Random;
|
|
import java.util.concurrent.locks.Lock;
|
|
import java.util.concurrent.locks.ReentrantLock;
|
|
|
|
@ThreadSafe
|
|
public class LoopyCallGraph {
|
|
private Lock lock = new ReentrantLock();
|
|
private int count = 0;
|
|
private Random random = new Random();
|
|
|
|
public void entry() {
|
|
if (random.nextBoolean()) {
|
|
increase(); // this could look like an unprotected path to a call to dec()
|
|
} else {
|
|
lock.lock();
|
|
dec();
|
|
lock.unlock();
|
|
}
|
|
}
|
|
|
|
private void increase() {
|
|
lock.lock();
|
|
count = 10;
|
|
lock.unlock();
|
|
entry(); // this could look like an unprotected path to a call to dec()
|
|
}
|
|
|
|
private void dec() {
|
|
count--;
|
|
}
|
|
} |