"szz_find_bug_introducers-0.1.jar" stalls for a long time Kafka 2.1.1 #28
Comments
|
|
wait, a long long time... |
|
Hi, so you didn't get any exception like the one I showed?
|
|
@djaekim Ran for 24 hours |
|
Get an empty |
|
Hello, Nice to see that you find the project interesting and wants to use it. And great that you've found some projects where this algorithm needs to get it's hands dirty. Just to confirm, I've runned the algorithm onto the apache/mahout project and I got the same result as you. So I've tried a couple of different ways to solve it. For this particular project(apache/mahout) I've tried to split the issues to run on several instances of the algorithm to:
So my result for the mahout project there where around 350 issues or something, right? Running the algorithm on the second half of the issues got a result in about 30 min. However, the first part took longer time and I'm suspecting that one commit is huge(maybe one or several huge files were deleted?). Anyway, one way to solve it, until I've optimized the step which check for partial fixes, you can try to split the issues.json into several files and let the algorithm run on them separately. And as said, to speed up things, distribute it on several computers to let them run in parallel. After they're done, merge the results and you have the same as you would have with a single instance runned. Another way, with the penalty of evaluating lesser amounts of commits, is to lower the depth for the graphs like java -jar szz_find_bug_introducers-0.1.jar -d 1 -r -i . It's defaulting to 3 which makes it go two commits back in history for each line. My spec for the runs was a Macbook Pro 13' , Intel i5, 16GB Ram and I used the configuration java -Xmx=6G .... |
|
@wogscpar Thank you for your prompt reply. Now, most projects can be analyzed normally, except strom. By the way, what impact will |
|
I've runned this on the apache/hadoop and from what I found out is that it include quite many code changes which makes the commit.json to be huge. I've implemented an option to not include the rows of code in the result and just save the linenumbering(since the code is only essential if you want to try out the experimental distanceintroducerfinder). In the simplefinder, only the lines are useful. As for the -d 1 option, it makes the algorithm to only look one commit behind in history. If you increase it, it will try to go through the as many commits as you specify with the -d option. I also implemented a optimization which makes the revisioncombinationgenerator not generate a full list with combinations but instead do it on the fly with a loop. |
Looking forward to update |
|
There's now an update where it's possible to omit the rows of code. It will, as stated in the commit remove the outofmemory(which means that FileNotFoundexception will not occur either) but will not solve the issue of the algorithm being slow. |
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First of all, I really appreciate your work on making SZZ algorithm public. This is truly helpful for researchers and practitioners.
Secondly, I am not using it with docker, and I am windows user.
Questions:
[1] I noticed that annotation.json is created quickly, however, the command line still shows "trying to find potential bug introducing commit" and stalls for a very long time. Based on the documentation, if "annotation.json" has same information as "fix_and_introducers_pairs.json", but shows details about bug introducing file rather commit, I do not understand why it stalls for a long time to get commits.
As soon as I run the program following happens
A.
B. inside each one I already have
C. however, it stalls for a very long time here.
[2] I was wondering how would i be able to get file introducing the bug rather than commit level? Can I traverse the annotation.json and look for filePath?
thank you!
The text was updated successfully, but these errors were encountered: