An implementation of the SZZ algorithm, i.e., an approach to identify bug-introducing commits.

SZZ Unleashed

SZZ Unleashed is an implementation of the SZZ algorithm, i.e. an approach to identify bug-introducing commits, introduced by Śliwerski et al's in "When Do Changes Induce Fixes?", in Proc. of the International Workshop on Mining Software Repositories, May 17, 2005. The implementation uses "line number mappings" as proposed by Williams and Spacco in "SZZ Revisited: Verifying When Changes Induce Fixes", in Proc. of the Workshop on Defects in Large Software Systems, July 20, 2008.

This repository responds to the call for public SZZ implementations by Rodríguez-Pérez, Robles, and González-Barahona. "Reproducibility and Credibility in Empirical Software Engineering: A Case Study Based on a Systematic Literature Review of the use of the SZZ Algorithm", Information and Software Technology, Volume 99, 2018.

If you find SZZ Unleashed useful for your research, please cite our paper:

  • Borg, M., Svensson, O., Berg, K., & Hansson, D., SZZ Unleashed: An Open Implementation of the SZZ Algorithm - Featuring Example Usage in a Study of Just-in-Time Bug Prediction for the Jenkins Project. In Proc. of the 3rd ACM SIGSOFT International Workshop on Machine Learning Techniques for Software Quality Evaluation (MaLTeSQuE), pp. 7-12, 2019. arXiv preprint arXiv:1903.01742.

Table of Contents

  1. Background
  2. Running SZZ Unleashed
  3. SZZ Unleashed with Docker
  4. Example Application: Training a Classifier for Just-in-Time Bug Prediction
  5. Examples and executables
  6. Authors

Background

The SZZ algorithm is used to find bug-introducing commits from a set of bug-fixing commits. The bug-introducing commits can be extracted either from a bug tracking system such as Jira or simply by searching for commits that state that they are fixing something. The identified bug-introducing commits can then be used to support empirical software engineering research, e.g., defect prediction or software quality. As an example, this implementation has been used to collect training data for a machine learning-based approach to risk classification of individual commits, i.e., training a random forest classifier to highlight commits that deserve particularily careful code review. The work is described in a MSc. thesis from Lund University.

Running SZZ Unleashed

Building and running SZZ Unleashed requires Java 8 and Gradle. Python is required to run the supporting scripts and Docker must be installed to use the provided Docker images. All scripts and compilations has been tested on Linux and Mac, and partly on Windows 10.

The figure shows a suggested workflow consisting of four steps. Step 1 and Step 2 are pre-steps needed to collect and format required data. Step 3 is SZZ Phase 1, i.e., identifying bug-fixing commits. Step 4 is SZZ Phase 2, i.e., identifying bug-introducing commits. Steps 1-3 are implemented in Python scripts, whereas Step 4 is implemented in Java.

SZZ Unleashed workflow

Step 1. Fetch issues (SZZ pre-step)

To get issues one needs a bug tracking system. As an example the project Jenkins uses Jira. From here it is possible to fetch issues that we then can link to bug fixing commits.

We have provided an example script that can be used to fetch issues from Jenkins issues (see 1 in the figure). In the directory fetch_jira_bugs, one can find the fetch.py script. The script has a jql string which is used as a filter to get certain issues. Jira provides a neat way to test these jql strings directly in the web page. Change to the advanced view and then enter the search criteria. Notice that the jql string is generated in the browser's url bar once enter is hit.

To fetch issues from Jenkins Jira, just run:

python fetch.py --issue-code <issue_code> --jira-project <jira_project_base_url>

passing as parameters the code used for the project issues on Jira and the name of the Jira repository of the project (e.g., issues.jenkins-ci.org). The script creates a directory with issues (see issues folder in the figure). These issues will later on be used by the find_bug_fixes.py script.

A more thorough example of this script can be found here.

Step 2. Preprocess the git log output (SZZ pre-step)

Second we need to convert the git log output to something that can be processed. That requires a local copy of the repository that we aim to analyze, Jenkins Core Repository. Once cloned, one can now run the git_log_to_array.py script (see 2 in the figure). The script requires an absolute path to the cloned repository and a SHA-1 for an initial commit.

python git_log_to_array.py --from-commit <SHA-1_of_initial_commit> --repo-path <path_to_local_repo>

Once executed, this creates a file gitlog.json that can be used together with issues that we created with the fetch.py script.

An example of this script and what it produces can be found in the examples.

Step 3. Identify bug-fixing commits (SZZ Phase 1)

Now, using the find_bug_fixes.py (see 3 in the figure) and this file, we can get a json file that contains the issue and its corresponding commit SHA-1, the commit date, the creation date and the resolution date. Just run:

python find_bug_fixes.py --gitlog <path_to_gitlog_file> --issue-list <path_to_issues_directory> --gitlog-pattern "<a_pattern_for_matching_fixes>"

The output is issue_list.json which is later used in the SZZ algorithm.

An example output of this script can be found in the examples.

Identify bug-introducing commits (SZZ Phase 2)

This implementation works regardless which language and file type. It uses JGIT to parse a git repository.

To build a runnable jar file, use the gradle build script in the szz directory like:

gradle build && gradle fatJar

Or if the algorithm should be run without building a jar:

gradle build && gradle runJar

The algorithm tries to use as many cores as possible during runtime.

To get the bug introducing commits from a repository using the file produced by the previous issue to bug fix commit step, run (see 4 in the figure):

java -jar szz_find_bug_introducers-<version_number>.jar -i <path_to_issue_list.json> -r <path_to_local_repo>

Output from SZZ Unleashed

As shown in the figure, the output consists of three different files: commits.json, annotations.json and fix_and_bug_introducing_pairs.json.

The commits.json file includes all commits that have been blamed to be bug introducing but which haven't been analyzed by anything.

The annotations.json is a representation of the graph that is generated by the algorithm in the blaming phase. Each bug fixing commit is linked to all possible commits which could be responsible for the bug. Using the improvement from Williams et al's, the graph also contains subgraphs which gives a deeper search for responsible commits. It enables the algorithm to blame other commits than just the one closest in history for a bug.

Lastly, the fix_and_bug_introducing_pairs.json includes all possible pairs which could lead to a bug introduction and fix. This file is not sorted in any way and it includes duplicates when it comes to both introducers and fixes. A fix can be made several times and a introducer could be responsible for many fixes.

Configuring SZZ Unleashed

A description of how to configure SZZUnleashed further can be found in the examples.

Use SZZ Unleashed with Docker

A more thorough instruction in using Docker to produce the results can be found in doc/Docker.md. Below is a very brief instruction.

There exists a Dockerfile in the repository. It contains all the steps in chronological order that is needed to generate the fix_and_bug_introducing_pairs.json. Simply run this command in the directory where the Dockerfile is located:

docker build -t ssz .

Then start a temporary docker container:

docker run -it --name szz_con szz ash

In this container it is possible to study the results from the algorithm. The results are located in ./szz/results.

Lastly, to copy the results from the container to your own computer run:

docker cp szz_con:/root/szz/results .

Note that the temporary container must be running while the docker cp command is executed. To be sure, check that the szz_con is listed when running:

docker ps

Example Application: Training a Classifier for Just-in-Time Bug Prediction

To illustrate what the output from SZZ Unleashed can be used for, we show how to train a classifier for Just-in-Time Bug prediction, i.e., predicting if individual commits are bug-introducing or not. We now have a set of bug-introducing commits and a set or correct commits. We proceed by representing individual commits by a set of features, based on previous research on bug prediction.

Code Churns

The most simple features are the code churns. These are easily extracted by just parsing each diff for each commit. The ones that are extracted are:

  1. Total lines of code - Which simply is how many lines of code in total for all changed files.
  2. Churned lines of code - This is how many lines that have been inserted.
  3. Deleted lines of code - The number of deleted lines.
  4. Number of Files - The total number of changed files.

To get these features, run: python assemble_code_churns.py <path_to_repo> <branch>

Diffusion Features

The diffusion features are:

  1. The number of modified subsystems.
  2. The number of modified subdirectories.
  3. The entropy of the change.

To extract the diffusion features, just run: python assemble_diffusion_features.py --repository <path_to_repo> --branch <branch>

Experience Features

Maybe the most sensitive feature group. The experience features are the features that measure how much experience a developer has, calculated based on both overall activity in the repository and recent activity.

The features are:

  1. Overall experience.
  2. Recent experience.

The script builds a graph to keep track of each authors experience. The initial run is: python assemble_experience_features.py --repository <repo_path> --branch <branch> --save-graph

This results in a graph that the script below uses for future analysis

To rerun the analysis without generating a new graph, just run: python assemble_experience_features.py --repository <repo_path> --branch <branch>

History Features

The history is represented by the following:

  1. The number of authors in a file.
  2. The time between contributions made by the author.
  3. The number of unique changes between the last commit.

Analogous to the experience features, the script must initially generate a graph where the file meta data is saved. python assemble_history_features.py --repository <repo_path> --branch <branch> --save-graph

To rerun the script without generating a new graph, use: python assemble_history_features.py --repository <repo_path> --branch <branch>

Purpose Features

The purpose feature is just a binary feature representing whether a commit is a fix or not. This feature can be extracted by running:

python assemble_purpose_features.py --repository <repo_path> --branch <branch>

Coupling

A more complex type of features are the coupling features. These indicate how strong the relation is between files and modules for a revision. This means that two files can have a relation even though they don't have a relation inside the source code itself. By mining these, features that give indications of how many files that a commit actually has made changes to are found.

The mining is made by a Docker image containing the tool code-maat.

Note that calculating these features is time-consuming. They are extracted by:

python assemble_features.py --image code-maat --repo-dir <path_to_repo> --result-dir <path_to_write_result>
python assemble_coupling_features.py <path_to_repo>

It is also possible to specify which commits to analyze. This is done with the CLI option --commits <path_to_file_with_commits>. The format of this file is just lines where each line is equal to the corresponding commit SHA-1.

If the analysis is made by several Docker containers, one has to specify the --assemble option which stands for assemble. This will collect and store all results in a single directory.

The script can check if there are any commits that haven't been analyzed. To do that, specify the --missing-commits option.

Classification

Now that all features have been extracted, the training and testing of the machine learning classifier can be made. In this example, we train a random forest classifier. To do this, run the model script in the model directory:

python model.py train

Examples and executables

In the examples directory, one can find documents containing descriptions about each script. There is also a data directory containing data produced by the scripts. It can be used to either study how the output should look like or if anyone just wants a dataset to train on.

Authors

Oscar Svensson Kristian Berg

Comments
  • FileNotFoundError in git_log_to_array.py

    FileNotFoundError in git_log_to_array.py

    FileNotFoundError exception in git_log_to_array.py, see below.

    Cloned jenkins to C:\Code\jenkins and provided absolute path to script. Tried a few variations of separators in file path. Not sure which file the system is looking for.

    C:\Code\SZZUnleashed\fetch_jira_bugs>python git_log_to_array.py --repo-path C:/Code/jenkins
    Traceback (most recent call last):
      File "git_log_to_array.py", line 43, in <module>
        git_log_to_json(init_hash, path_to_repo)
      File "git_log_to_array.py", line 14, in git_log_to_json
        stdout=subprocess.PIPE).stdout.decode('ascii').split()
      File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\subprocess.py", line 403, in run
        with Popen(*popenargs, **kwargs) as process:
      File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\subprocess.py", line 709, in __init__
        restore_signals, start_new_session)
      File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\subprocess.py", line 997, in _execute_child
        startupinfo)
    FileNotFoundError: [WinError 2] The system cannot find the file specified
    
  • Short description of repo and tags need an update

    Short description of repo and tags need an update

    The short description of the repo should be corrected. Instead of

    A complete implementation of the SZZ algorithm as described by Zeller et al's.

    I suggest

    An implementation of the SZZ algorithm, i.e., an approach to identify bug-introducing commits.

    The reference to the work by the SZZ authors is anyway first in the README.md... on top of that "Zeller et al." is wrong, since it's actually "Śliwerski et al."

    Also, I suggest adding a few more tags to support findability of this repo from the software engineering research community. I suggest adding: "defect-prediction", "mining-software-repositories", and "software-engineering-research".

  • Parameters passed when running the jar file

    Parameters passed when running the jar file

    I may be totally wrong here, but it seems to me that Configuration.java supports more parameters than the two specified in Readme.md for the szz_find_bug_introducers-<version_number>.jar file. Maybe an explanation about them should be added in the Readme.md file.

    In particular, I think that it may be important to explain the parameter that sets the number of cores during the execution. Currently, the Readme.md file states:

    The algorithm tries to use as many cores as possible during runtime.

    However, the option to enable the user to set the number of cores seems to have been implemented in Configuration.java. I think this possibility should be explained in Readme.md since it may be relevant for the users.

    What do you think?

  • ClassCastException in GitParser.java:342

    ClassCastException in GitParser.java:342

    Successfully built szz_find_bug_introducers-0.1.jar with gradle. The res1000.json file appears to be populated with correct data.

    Not sure if it is related, an also not sure what the purpose of the file results\result0\commits.json is, but it is missing and a FileNotFoundException is thrown.

    If this is not a bug, then the instructions need to be updated to explain what needs to be present before running the jar file.

    Output and stack trace:

    java -jar szz_find_bug_introducers-0.1.jar -i C:\Code\SZZUnleashed\fetch_jira_bugs\issues\res1000.json -r C:\Code\jenkins
    [main] INFO Main - Checking available processors...
    [main] INFO Main - Found 8 processes!
    [Thread-0] INFO parser.GitParserThread - Started process...
    Exception in thread "Thread-0" java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
            at parser.GitParser.readBugFixCommits(GitParser.java:342)
            at parser.GitParserThread.run(GitParserThread.java:94)
    [Thread-1] INFO parser.GitParserThread - Started process...
    Exception in thread "Thread-1" java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Map
            at parser.GitParser.readBugFixCommits(GitParser.java:342)
            at parser.GitParserThread.run(GitParserThread.java:94)
    [Thread-2] INFO parser.GitParserThread - Started process...
    Exception in thread "Thread-2" java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Map
            at parser.GitParser.readBugFixCommits(GitParser.java:342)
            at parser.GitParserThread.run(GitParserThread.java:94)
    [Thread-3] INFO parser.GitParserThread - Started process...
    [Thread-4] INFO parser.GitParserThread - Started process...
    [Thread-5] INFO parser.GitParserThread - Started process...
    [Thread-5] INFO parser.GitParserThread - Found 0 number of commits.
    [Thread-5] INFO parser.GitParserThread - Checking each commits diff...
    [Thread-5] INFO parser.GitParserThread - Parsing difflines for all found commits.
    [Thread-5] INFO parser.GitParserThread - Saving parsed commits to file
    Exception in thread "Thread-4" java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Map
            at parser.GitParser.readBugFixCommits(GitParser.java:342)
            at parser.GitParserThread.run(GitParserThread.java:94)
    [Thread-5] INFO parser.GitParserThread - Building line mapping graph.
    [Thread-6] INFO parser.GitParserThread - Started process...
    [Thread-5] INFO parser.GitParserThread - Saving results to file
    [Thread-6] INFO parser.GitParserThread - Found 0 number of commits.
    [Thread-6] INFO parser.GitParserThread - Checking each commits diff...
    [Thread-5] INFO parser.GitParserThread - Trying to find potential bug introducing commits...
    [Thread-6] INFO parser.GitParserThread - Parsing difflines for all found commits.
    [Thread-6] INFO parser.GitParserThread - Saving parsed commits to file
    [Thread-5] INFO parser.GitParserThread - Saving found bug introducing commits...
    [Thread-7] INFO parser.GitParserThread - Started process...
    [Thread-6] INFO parser.GitParserThread - Building line mapping graph.
    [Thread-7] INFO parser.GitParserThread - Found 0 number of commits.
    [Thread-6] INFO parser.GitParserThread - Saving results to file
    [Thread-7] INFO parser.GitParserThread - Checking each commits diff...
    [Thread-7] INFO parser.GitParserThread - Parsing difflines for all found commits.
    [Thread-6] INFO parser.GitParserThread - Trying to find potential bug introducing commits...
    [Thread-7] INFO parser.GitParserThread - Saving parsed commits to file
    [Thread-6] INFO parser.GitParserThread - Saving found bug introducing commits...
    [Thread-7] INFO parser.GitParserThread - Building line mapping graph.
    [Thread-7] INFO parser.GitParserThread - Saving results to file
    [Thread-7] INFO parser.GitParserThread - Trying to find potential bug introducing commits...
    [Thread-7] INFO parser.GitParserThread - Saving found bug introducing commits...
    Exception in thread "Thread-3" java.lang.ClassCastException: org.json.simple.JSONArray cannot be cast to java.util.Map
            at parser.GitParser.readBugFixCommits(GitParser.java:342)
            at parser.GitParserThread.run(GitParserThread.java:94)
    java.io.FileNotFoundException: results\result0\commits.json (The system cannot find the file specified)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileReader.<init>(Unknown Source)
            at diff.SimplePartition.mergeFiles(SimplePartition.java:140)
            at Main.main(Main.java:65)
    java.io.FileNotFoundException: results\result1\commits.json (The system cannot find the file specified)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileReader.<init>(Unknown Source)
            at diff.SimplePartition.mergeFiles(SimplePartition.java:140)
            at Main.main(Main.java:65)
    java.io.FileNotFoundException: results\result2\commits.json (The system cannot find the file specified)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileReader.<init>(Unknown Source)
            at diff.SimplePartition.mergeFiles(SimplePartition.java:140)
            at Main.main(Main.java:65)
    java.io.FileNotFoundException: results\result3\commits.json (The system cannot find the file specified)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileReader.<init>(Unknown Source)
            at diff.SimplePartition.mergeFiles(SimplePartition.java:140)
            at Main.main(Main.java:65)
    java.io.FileNotFoundException: results\result4\commits.json (The system cannot find the file specified)
            at java.io.FileInputStream.open0(Native Method)
            at java.io.FileInputStream.open(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileInputStream.<init>(Unknown Source)
            at java.io.FileReader.<init>(Unknown Source)
            at diff.SimplePartition.mergeFiles(SimplePartition.java:140)
            at Main.main(Main.java:65)
    
  • I found a

    I found a "fetch.py" error

    I noticed that the contents of your res0.json, res1000.json and res2000.json are exactly the same.

    Regardless of what start_at and max_results are, it will get all the data (no difference).

    It always,

    {"expand":"schema,names","startAt":0,"maxResults":50,"total":2445,"issues":
    [{"expand":"operations,versionedRepresentations,editmeta,changelog,renderedFields",
    "id":"188567","self":"https://issues.jenkins-ci.org/rest/api/2/issue/188567","key":
    "JENKINS-49642","fields":{"issuetype":
    {"self":"https://issues.jenkins-ci.org/rest/api/2/issuetype/1","id":"1",
    "description":"A problem which impairs or prevents the functions of the product.","iconUrl":
    
    ...
    

    You can copy the following string to your browser URL.

    https://issues.jenkins-ci.org/rest/api/2/search?jql=project%20%3D%20JENKINS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20core%20AND%20created%20%3C%3D%20%222018-02-20%2010%3A34%22%20ORDER%20BY%20created%20DESC&start_at=0&max_results=1
    
    https://issues.jenkins-ci.org/rest/api/2/search?jql= \
    project = JENKINS AND issuetype = Bug AND status in (Resolved, Closed) \
    AND resolution = Fixed AND component = core \
    AND created <= "2018-02-20 10:34" \
    ORDER BY created DESC&start_at=0&max_results=1
    
  • cannot find bug fixing issues in Jira Projects of Apache Software Foundation

    cannot find bug fixing issues in Jira Projects of Apache Software Foundation

    The analysis of any project in the jira of the apache software foundations fails.

    As example, we executed

    git clone https://github.com/apache/accumulo
    python3 fetch.py --issue-code ACCUMULO --jira-project issues.apache.org/jira
    
    python3 git_log_to_array.py --repo-path ./accumulo --from-commit 31b54248176f320cc15f432ece29f998a0d3a363
    
    python3 find_bug_fixes.py --gitlog gitlog.json --issue-list ./issues
    

    The last script cannot find any matching bug-fixing commit while reading from the commit messages there are several commits reporting the Jira issue id and clearly reporting "fixed" in the commit message.

  •  java.lang.ClassCastException when casting JSONArray to JSONObject

    java.lang.ClassCastException when casting JSONArray to JSONObject

    The "issues" subfolder is created, but it's empty.

    Here is the stack trace:

    [main] INFO Main - Checking available processors...
    [main] INFO Main - Found 8 processes!
    Exception in thread "main" java.lang.ClassCastException: org.json.simple.JSONArray cannot be cast to org.json.simple.JSONObject
            at diff.SimplePartition.splitJSON(SimplePartition.java:52)
            at diff.SimplePartition.splitFile(SimplePartition.java:121)
            at Main.main(Main.java:44)
    
  • UnicodeEncodeError from fetch.py

    UnicodeEncodeError from fetch.py

    The fetch script results in a UnicodeEncodeError, see below. An empty file "res0.json" is created in the issues subdirectory.

    Environment: Python 3.6.6 on Win10.

    python fetch.py
    Total issue matches: 2435
    Progress: | = 1000 issues
    Traceback (most recent call last):
      File "fetch.py", line 53, in <module>
        fetch()
      File "fetch.py", line 46, in fetch
        f.write(conn.read().decode('utf-8'))
      File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\encodings\cp1252.py", line 19, in encode
        return codecs.charmap_encode(input,self.errors,encoding_table)[0]
    UnicodeEncodeError: 'charmap' codec can't encode character '\u2193' in position 320915: character maps to <undefined>
    
  • Has the entire commit induced a bug?

    Has the entire commit induced a bug?

    I have two questions: First, in the fix_and_bug_introducers.json, is the order [fixing, buggy] or the opposite? I am confused because commits.json which is supposed to contain buggy files has the commit numbers which are at location 0 in the pairs in fix_and_bug_introducers.json? Second, when SZZUnleashed finds a commit as buggy would it label the entire commit as buggy or just a few files are labelled as buggy? Apparently commits.json contains the entire commit(as it appears in GitHub), and not just a few files that might have caused the bug.  If someone can kindly answer these I'd be grateful.

  • Fetching issues does not work properly

    Fetching issues does not work properly

    Jenkins or Jira issues are not downloaded correctly. The fetch.py file's function fetch downloads only 50 issues at a time and pagination does not work either as everytime the 50 first issues are downloaded.

    I tested the code with several Jira projects and the Jenkins project provided as an example. All tested projects had the same problem.

    Apparently the Jira REST API's syntax has changed which causes the problem. I fixed the issue by changing start_at to startAt and max_results to maxResults. Example of my fix is below

        request = 'https://' + jira_project_name + '/rest/api/2/search?'\
            + 'jql={}&startAt={}&maxResults={}'
    
  • Unclear Figure 3

    Unclear Figure 3

    I'm looking at Figure 3 in your paper (BTW, nice graphics!) and I don't understand why line 3 in Commit 3 is not blamed to either Commit 2 or Commit 1.

    Could you please clarify?

  • Use github as an issue tracker

    Use github as an issue tracker

    A lot of open-source projects rely on Github issues for their issue tracker. Since researchers work a lot with open source repositories, I think it's extremely valuable to have a support for retrieving issues from Github issues and using it with SZZUnleashed.

    Could this feature be added?

  • Fix bugIntroducers pair order

    Fix bugIntroducers pair order

    Fixes #38.

    Simply reverse the pair order before adding them to bugIntroducers. Also pass pair[1] to isPartialFix as pair[1] corresponds to the bug-fixing commit.

    A more involved alternative would be to flip the order of RevisionCombinationGenerator to issues-introducers instead of introducers-issues.

  • Wrong pair order in SimpleBugIntroducerFinder

    Wrong pair order in SimpleBugIntroducerFinder

    It seems to me that in the following code snippet

    https://github.com/wogscpar/SZZUnleashed/blob/79f369fe2ccd2ae8c12d4e38edf71e7d988a8c68/szz/src/main/java/heuristics/SimpleBugIntroducerFinder.java#L180-L207

    pair[0] is a bug-introducing commit, and pair[1] is a bug-fixing commit as defined in the issue list.

    However, in line 193 (as well as in line 224), I think the order of the pair should be (bug-fixing commit, bug-introducing commit), so (pair[1], pair[0]).

    Is this correct or am I missing something?

  • output result make me confuse

    output result make me confuse

    in commit.json file, the line number in the diff dict , the result seen not right, it should +1 ,that is the really right line number image execute the cmd : git blame -l b831acd9854b525d680ca72fd218c848121b9d3f^ -- core/src/test/java/hudson/model/ViewTest.java, the delete code line number is actually is 101, not 100, add dict result is the same should +1 when write result to file image In addition, the annotation graph result make me confuse, the bug-introduction in this file, 101 line number, from git blame command show commit hash should be 67827c7eaac821aa22a2f26bd4dbe7d44470b6c9 not 05b46659e451c316fb5f1a5243c49b9a84a50702 that result in annotations.json image

    the code in SZZUnleashed/szz/src/main/java/parser/GitParser.java 212, the var i should be index ???? image

Identify I2C devices from a database of the most popular I2C sensors and other devices

I2C Detective Identify I2C devices from a database of the most popular I2C sensors and other devices. For more information see http://www.technoblogy.

Oct 14, 2022
weggli is a fast and robust semantic search tool for C and C++ codebases. It is designed to help security researchers identify interesting functionality in large codebases.
weggli is a fast and robust semantic search tool for C and C++ codebases. It is designed to help security researchers identify interesting functionality in large codebases.

weggli is a fast and robust semantic search tool for C and C++ codebases. It is designed to help security researchers identify interesting functionality in large codebases.

Dec 1, 2022
OpenDCDiag is an open-source project designed to identify defects and bugs in CPUs.

OpenDCDiag is an open-source project designed to identify defects and bugs in CPUs. It consists of a set of tests built around a sophisticated CPU testing framework. OpenDCDiag is primarily intended for, but not limited to, Data Center CPUs.

Oct 24, 2022
Header only implementation of Progressive Photon Mapping: A Probabilistic Approach(PPMAPA) in C++.
Header only implementation of Progressive Photon Mapping: A Probabilistic Approach(PPMAPA) in C++.

ppmapa Header only implementation of Progressive Photon Mapping: A Probabilistic Approach(PPMAPA) in C++. In this reformulation of (stochastic) progre

Jul 20, 2022
Demo exploit code for CVE-2020-27904, a tfp0 bug.

xattr-oob-swap CVE-2020-27904: a tfp0 bug for macOS 10.15.x and below. Demo exploit code for my talk at BlackHat ASIA 2021. The vulnerability has been

Nov 9, 2022
Reproducible example of overlay and overlay mac driver bug

problem It's been observed under certain circumstances that MacOS overlay and overlay2 storage drivers cause the syscall copy_file_range to return zer

Dec 7, 2021
A fork of the kwin blur effect that solve the corners bug.
A fork of the kwin blur effect that solve the corners bug.

Kwin blur effect - Respect rounded corners This kwin effect is a fork of the default kwin blur effect, with minimal changes to solve the "plasma korne

Nov 8, 2022
🐧MAJOR BUG GRANTS ROOT FOR ALL MAJOR LINUX DISTRIBUTIONS

?? MAJOR BUG GRANTS ROOT FOR ALL MAJOR LINUX DISTRIBUTIONS CTF quality exploit bla bla irresponsible disclosure terminal: [email protected]:~$ wget https://g

Jun 22, 2022
C#-like properties for C++20. This was made to demonstrate a bug in ClangFormat.

cpp20-property C#-like properties for C++20. Example usage #include <iostream> #include <Propery.hpp> class ProperyTest { public: zsl::Property<

Jun 9, 2022
Cool and different approach to Strimer Plus. Colorful scrolling text message. It's ready for you!
Cool and different approach to Strimer Plus. Colorful scrolling text message. It's ready for you!

Strimer Plus DIY Version: 2021.10.27 Author: Murat TAMCI Web Site: www.themt.co Note: In loving memory of my grandfather (Ahmet Ozdil) Welcome to Stri

Jan 10, 2022
Code accompanying our SIGGRAPH 2021 Technical Communications paper "Transition Motion Tensor: A Data-Driven Approach for Versatile and Controllable Agents in Physically Simulated Environments"
Code accompanying our SIGGRAPH 2021 Technical Communications paper

SIGGRAPH ASIA 2021 Technical Communications Transition Motion Tensor: A Data-Driven Framework for Versatile and Controllable Agents in Physically Simu

Apr 21, 2022
Implementation of Linking Loader Algorithm using CPP.

Linking Loader Implementation in CPP Instructions for executing the file First run the Linking_Loader_PASS1.cpp file using the cmd -> g++ Linking_Load

Oct 15, 2022
Solves a given NxN wordsearch in under 0.3 seconds at most using Rabin-Karp string algorithm.

ASSIGNMENT 2 The Information of the Creator: ASSIGNMENT 2 Author: Lukas Waschuk CCID: lwaschuk Date: 03-20-2021 The Purpose of Your Program: This prog

May 17, 2022
Daily challenge on algorithm, using different languages.

??‍?? DailyChallenges Content General Information Setup Usage Languages Enhancements ?? General Information These Daily challenges are aimed at growin

Mar 7, 2022
In this project ı'am trying to implement dijkstra algorithm with adjacency list representation.

AirportCheapestPath In this project, I have tried to make a flight advisor program to the 3rd party users. To do that, This program gets the data of a

Nov 7, 2022
Example program demonstrating the Meijster's distance transform algorithm.
Example program demonstrating the Meijster's distance transform algorithm.

Distance Transform The distance transform operation consist in finding the shortest distance of a black pixel to a white one. This project demonstrate

Nov 15, 2021
Add anything about data structure and algorithm in any language.

Hacktoberfest 2021 Follow the README below to get started! Note : This repo is excluded from the Hacktoberfest but you can still contribute and the re

Nov 13, 2022
DG-Mesh-Optimization - Discontinuous Galerkin (DG) solver coupled with a Quasi-Newton line-search algorithm to optimize the DG mesh.
DG-Mesh-Optimization - Discontinuous Galerkin (DG) solver coupled with a Quasi-Newton line-search algorithm to optimize the DG mesh.

Date written: December 2020 This project was pursued as my final project for MECH 579 (Multidisciplinary Design Optimization) at McGill University, ta

Sep 18, 2022