Problem

In the current implementation of getMethodSignatureInSubClass within ICFGDotExporter.java, there's a logical oversight where the method could potentially include the target method in its own set of sub-class method signatures. This leads to the incorrect behavior in connectEdgesToSubClasses, where a method might connect an edge from its starting statement back to itself, causing confusion in the call graph visualization.

Before applying the PR change:
source in connectEdgesToSubClasses:

Set<MethodSignature> methodSignatureInSubClass =
        getMethodSignatureInSubClass(source, target, callgraph);

Here result methodSignatureInSubClass will contains target

sink in connectEdgesToSubClasses:

calls.put(
                  method.get().getBody().getStmtGraph().getStartingStmt().hashCode(),
                  subclassmethodSignature);

which will also overwrite previous entry set where call the connectEdgesToSubClasses in computeCalls

 if (stmt.containsInvokeExpr()) {
            MethodSignature target = stmt.getInvokeExpr().getMethodSignature();
            int hashCode = stmt.hashCode();
            calls.put(hashCode, target);
            // compute all the classes that are made to the subclasses as well
            connectEdgesToSubClasses(source, target, view, calls, callgraph);

Solution

This PR addresses the issue by adding an additional check in the filter operation within getMethodSignatureInSubClass. The updated logic ensures that the target method signature is explicitly excluded from the set of callable sub-class signatures.

Changes Made

• Updated the filter condition to exclude the target from the results if it matches the source.

Thank you for considering this fix to improve the accuracy of our tool.