resess / Slicer4J

Slicer4J is an accurate, low-overhead dynamic slicer for Java programs.
MIT License
39 stars 17 forks source link

Slicer4J doesn't include declaration of variable, on which variable from slice is data-dependent. #4

Closed ArtemUntila closed 2 years ago

ArtemUntila commented 2 years ago

Issue.java:

1.  public class Issue {
2.  
3.      public static void main(String[] args) {
4.          int b = 2;
5.          int a = 1 + b;
6.          System.out.println(a);
7.      }
8.  }

Running Slicer4J w.r.t. Issue:6 line:

cd scripts
python3 slicer4j.py -j .../issue.jar -o .../issue -b Issue:6 -m "Issue"

slice.log:

Issue:5
Issue:6

Despite variable a is data-dependent on variable b, the line with declaration of variable b wasn't included in slice.log.

In the example from README the same situation is observed:

For the example, slice.log contains:

SliceMe:4
SliceMe:7
SliceMe:9

Which indicates that the slice is:

4.        if (args.length > 0){
7.            parsed = null;
9.        System.out.println(parsed.length);

In this example line with declaration of variable parsed also wasn't included in slice.log.

Is such behaviour expected?

khaled-e-a commented 2 years ago

For the Issue class:

4.          int b = 2;
5.          int a = 1 + b;

If you look at the raw slice, you'll notice that line 5 becomes int a = 3. This is due to constant propagation done by soot when creating the instrumented JAR. So it conceals the dependency of 5 on 4 as b does not appear in line 5 anymore. If b is not constant, it will be in the slice. Currently, I have no way of disabling the constant propagation in soot.

As for the readme example:

4.        if (args.length > 0){
7.            parsed = null;
9.        System.out.println(parsed.length);

the re-assignment of parsed at line 7 overwrites any value of parsed before line 7. So line 7 is not data-dependent on the definition of parsed. This is the expected behaviour.