wala / WALA

T.J. Watson Libraries for Analysis, with frontends for Java, Android, and JavaScript, and may common static program analyses
http://github.com/wala/WALA
Eclipse Public License 2.0
750 stars 221 forks source link

False positive of RTA points-to analysis #1393

Open tisble opened 4 months ago

tisble commented 4 months ago

Hi, I found a case that can help improving Wala. Please see the minimized code example below:

public class Example1 {
  public static void main(String[] args) {
      foo(new C1(), new C2());
  }
  public static void foo(C n1, C n2) {
      // code...
  }
}
interface C {}
class C1 implements C {}
class C2 implements C {}

In this example, the concrete type of the first parameter in foo should only be One as it is only initlialized by new One(), but Wala provides One and Two. The second parameter has similar issue.

Wala version: 1.6.4

Code

public void run() throws CallGraphBuilderCancelException, IOException, ClassHierarchyException {
    AnalysisScope scope = AnalysisScopeReader.instance.makeJavaBinaryAnalysisScope(INPUT_DIR, walaExclusionFile);
    IClassHierarchy cha = ClassHierarchyFactory.make(scope);
    Iterable<Entrypoint> entryPoints = Util.makeMainEntrypoints(cha); // default entry: main method
    AnalysisOptions options = new AnalysisOptions(scope, entryPoints);
    AnalysisCache cache = new AnalysisCacheImpl();
    CallGraphBuilder<InstanceKey> builder = Util.makeRTABuilder(options, cache, cha);
    PointerAnalysis<InstanceKey> pointerAnalysis = builder.getPointerAnalysis();
}
msridhar commented 3 months ago

HI @tisble I think there may be some confusion here. The RTA algorithm does not track data flow of objects. It assumes that if it sees a new expression for some class, then objects of that class may flow to any type-compatible variable. So here, it is correct for RTA to conclude that n1 and n2 each may point to objects of type either C1 or C2. I would expect a 0-CFA builder to be more precise. Does that make sense?