having trouble understanding JacksonCore_4b benchmark slicing criterion

[soneyahossain]

In the run_benchmarks.py file you generated slice for the following paramters:

"JacksonCore_4b": ("target/jackson-core-2.5.0-SNAPSHOT.jar", "org.junit.runner.JUnitCore com.fasterxml.jackson.core.util.TestTextBuffer", "com.fasterxml.jackson.core.util.TextBuffer", "587", "expandCurrentSegment", "JacksonCore_4b/target/test-classes/:JacksonCore_4b/target/dependency/*"),

when debugging I am not finding 587 line in the com.fasterxml.jackson.core.util.TextBuffer test class, neither did I find the expandCurrentSegment method. In the paper you mentioned that you used failing test assertion statement as the slicing criterion , but none of the criteria are taken from a test file. I am investigating this as I am having troubling generating slice from the test assertion as I mentioned in another issue. Any clarification will be highly appreciated.

[khaled-e-a]

As I don't have an automated build system to package test cases into the jar, run_benchmakrs assumes the users will build the Defects4J according to the default build system, so it won't have the test classes in the jar. Thus, the run_benchamrks slices from the failed line in the main jar. You can modify the build system and slice from test cases.

Also, it would also be amazing if you want to to contribute such automated build system to package tests with the main jar into the tool and submit it as a pull request.

[khaled-e-a]

Also, the way this benchmarks file runs, the line number (587) is for lines in the trace not the source code. the slicer4.py is the script that uses source code line numbers.

[DaisyPo]

Also, the way this benchmarks file runs, the line number (587) is for lines in the trace not the source code. the slicer4.py is the script that uses source code line numbers.

Excuse me, I read the code of run_benchmarks.py and slicer4j.py. The operation of parsing the slicing line in the two scripts looks the same.

[khaled-e-a]

Hi @DaisyPo

I did not understand your question, may you please clarify? did my above comments not resolve the issue for you?

Thank you.

[DaisyPo]

Hi @DaisyPo

I did not understand your question, may you please clarify? did my above comments not resolve the issue for you?

Thank you.

I mean the line number(587) is the line in the source code (com.fasterxml.jackson.core.util.TextBuffer:587). Then Slicer4j finds the criterion in the trace.log_icdg.log according to it. Am I understanding this correctly?

[DaisyPo]

Hi @DaisyPo

I did not understand your question, may you please clarify? did my above comments not resolve the issue for you?

Thank you.

I also have another question about the line number. When running the run_benchmarks.py, I find there is actually more than one line matching "LINENO:587:FILE:com.fasterxml.jackson.core.util.TextBuffer"in the trace.log_icdg.log, but the script just uses the last one it finds. Why do you just choose the last one but not try every line matched?
Thank you.

[khaled-e-a]

The run_benchmarks.py and slicer4.py run in different ways.

The run_benchmarks.py runs the Slicer4J JAR directly, the JAR does not know about source code line numbers, it only takes in as input the "Trace" line number, so the 587 is for lines in the trace not the source code, so you won't find it in the source code.

The slicer4j.py takes in the "source" line number, not the trace, as you pointed out, it translates the source line number to trace line number by scanning the trace and finding the last trace line for that source line number.

Thank you for pointing out that the slicer should slice from all lines instead of the last one, I will push a fix soon.

[DaisyPo]

The run_benchmarks.py and slicer4.py run in different ways.

The run_benchmarks.py runs the Slicer4J JAR directly, the JAR does not know about source code line numbers, it only takes in as input the "Trace" line number, so the 587 is for lines in the trace not the source code, so you won't find it in the source code.

The slicer4j.py takes in the "source" line number, not the trace, as you pointed out, it translates the source line number to trace line number by scanning the trace and finding the last trace line for that source line number.

Thank you for pointing out that the slicer should slice from all lines instead of the last one, I will push a fix soon.

Thank you for your answer, but the code I had a screen cut is from run_benchmark.py.
In this script, the slicing criterion for JacksonCore is in line 587 of the function expandCurrentSegment from com.fasterxml.jackson.core.util.TextBuffer:

Thus, I think 587 is the real line number in the source code. Or there is another version of run_benchmark.py?
Thank you.