upgrade to latest version of GZoltar
Closed this issue · 7 comments
I notice that Nopol uses GZoltar 0.1.1 at present. But as reported in the literature (see "You cannot fix what you cannot find!" [ICST 2019]), GZoltar 0.1.1 fails to include the faulty statements in the produced suspicious statement list for many bugs, while GZoltar v1.6.0 is capable of localizing more bugs. Therefore, I would like to ask if there is a necessity to enable Nopol to integrate the latest version of GZoltar (i.e., v1.7.3) so that Nopol may be able to repair more bugs.
I have already run GZoltar v1.7.3 on some bugs (e.g., Chart-1 in Defects4J) via the command line interface. It seems Nopol can integrate GZoltar v1.7.3 by enabling GZoltarFaultLocalizer.java to parse the matrix.txt and spectra.csv file.
I would like to ask if there is a necessity to enable Nopol to integrate the latest version of GZoltar (i.e., v1.7.3)
It's a great idea. However, some parts of the GZoltar API have changed, this may require some big changes.
PR much welcome!
Thank you for your reply! I'll try this work, but my current solution is:
- Nopol creates a command to run GZoltar for the given buggy program, and then invokes ProcessBuilder to execute this command;
- Nopol parses the files generated by GZoltar (e.g., matrix and spectra) to put the corresponding data into
Map<SourceLocation, List<fr.inria.lille.localization.TestResult>> results, which contains both suspicious locations and associated tests and is used for Nopol to do patch generation.
In this way, it seems we do not need to modify too much source code of the Nopol.
I prefer this solution personally, as I am more familiar with how to use the command line interface of GZoltar v1.7.3 than how to use its Java APIs (P.S. it would also be much appreciated if some guidelines can be provided to how to use the API of GZoltar).
I have already wrote a new FaultLocalizer in Nopol source code for GZoltar v1.7.3 and tested several bugs from Defects4J. This works well in localizing Chart bugs. However, when it comes to Closure bugs, which has much more unit tests (e.g., Closure-1 contains 222 test classes and 7911 test cases in total), the GZoltar v1.7.3 becomes very slow, costing at least 40 minutes, and generates a very large GZoltar.ser file that reaches up to 1.4 GB. On the contrast, the GZoltar 0.1.1 implemented in Nopol just costs less than 5 minites.
In this case, GZoltar v1.7.3 seems not so effective. Next I may try GZoltar v1.7.2 version to find the solution. Many thanks!
Thanks for the update. FYI, @martinezmatias is working a new implementation of a fault localizer.
Thank you so much for the information! It would be really appreciated if I could be kept updated about the new implementation of the fault localizer. And I am sorry that I am currently busy with another task. Once I have time, I will continue with this work I am very interested in. Thank you!
OK, closing for now, but we can still post our progress here