Short Introduction to This Paper

This paper deeply studied 395 patches of the Defects4J dataset. Quantitative properties (patch size and spreading) were automatically extracted, whereas qualitative ones (repair actions and patterns) were manually extracted using a thematic analysisbased approach. It found that:

1) the median size of Defects4J patches is four lines, and almost 30% of the patches contain only addition of lines;
2) 92% of the patches change only one file, and 38% has no spreading at all;
3) the top-3 most applied repair actions are addition of method calls, conditionals, and assignments, occurring in 77% of the patches;
4) nine repair patterns were found for 95% of the patches, where the most prevalent, appearing in 43% of the patches, is on conditional blocks.

These results are useful for researchers to perform advanced analysis on their techniques’ results based on Defects4J. Moreover, this set of properties can be used to characterize and compare different bug datasets

Highlights of This Paper

• The anatomy of the patches in Defects4J containing an extensive set of patch properties, consolidated into a JSON file and augmented with a web user-interface to facilitate exploration
• A bug dataset dissection methodology to extract valuable quantitative and qualitative properties regarding patches from bug datasets. The methodology is based on diff and advanced patch analysis and combines automated and manual thematic analysis
• A taxonomy of repair actions and patterns, resulted from manual analysis of patches according our methodology

Key Infomation

• Research questions:

  • What is the size distribution of Defects4J patches?
  • To what extent are Defects4J patches spread in source code?
  • What is the composition of Defects4J patches in terms of repair actions (additions, removals and modifications) over code elements (e.g. conditions and method calls)?
  • What repair patterns can be found in Defects4J using a manual thematic analysis?
• Data Collection: For each bug, first produced diff views between the buggy program version and its associated fixed version. These views served as source for data extraction and analysis

• Repair Patterns in the Defects4J Patches:

  • Conditional Block
  • Expression Fix
  • Wraps-with / Unwraps-from
  • Single Line
  • Wrong Reference
  • Missing Null-Check
  • Copy / Paste
  • Constant Change
  • Code Moving

Relevant Future Works

• Maybe some supplement for Defects4J's document
• Characterization and comparison between different bug datasets

URL

Dissection of a Bug Dataset: Anatomy of 395 Patches from Defects4J

Background

This post introduces 2 basic solutions about docker monitoring. And what's more, we want to dig into metrics exporting methods. In order to do some data analysis, we want to extract metrics in a usable/simple format (e.g. CSV). It's easy to query some metrics, but the tools paid less attention to export multiple metrics joined by timestamp(this can be some scenarios about data analysis, or dev daily report), we are going to build a small tools for this.

- Read the full article -

Part I Intruduction

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
-- Principles of Chaos

Using Chaos Engineering may be as simple as manually running kill -9 on a box inside of your staging environment to simulate failure of a service. Or, it can be as sophisticated as automatically designing and carrying out experiments in a production enviroment against a small but statistically significant fraction of live traffic.

The History of Chaos Engineering at Netflix: started in 2008

• Chaos Monkey: ball rolling, gaining notoriety for turning off services in the production environment
• Chaos Kong: transferred those benefits from the small scale to the very large
• Failure Injection Testing (FIT): the foundation for tackling the space in between

- Read the full article -

Short Introduction to This Paper

This paper introduces and explores the idea of data poisoning, a light-weight peer-architecture technique to inject faults into Python programs. This method requires very small modification to the original program, which facilitates evaluation of sensitivity of systems that are prototyped or modeled in Python. Actually this paper doesn't show much detail about the implementation, but the types of data poisoning it declares are very interesting.

Highlights of This Paper

• Data poisoning's symbolic expression
• Different types of data poisoning

Key Infomation

• Types of data poisoning: deterministic effect poisoning, intermittent effect poisoning (need define the lifetime of poisoned data), infectious/non-infectious poisoning

Relevant Future Works

• Only doing data poisoning is not enough, we should analysis the system's behaviour under different types of perturbation

URL

Data Poisoning: Lightweight Soft Fault Injection for Python

Short Introduction to This Paper

This paper describes the motivation, innovation, design, running example and future development of a Fault Inject Tool (FIT). This tool enables controlled causing of cloud platform issues such as resource stress and service or VM outages, the purpose being to observe the subsequent effect on deployed applications.

Highlights of This Paper

• The DICE FIT will address the need to generate various cloud agnostic faults at the VM Admin and Cloud Admin levels. So greater flexibility and the ability to generate multiple faults, relatively lightweight

Key Infomation

• Design: To access the VM level and issue commands the DICE FIT uses SSH to connect to the Virtual Machines and issue the commands. By using JSCH, the tool is able to connect to any VM that has SSH enabled and issue commands as a pre-defined user. This allows greater flexibility of commands as well as the installation of tools and dependences.

Relevant Future Works

• Containerised environments will also be considered as future FIT targets to help understand the effect on microservices when injecting faults to the underlying host as well as the integrity of the containerised deployment
• The CACTOS project will expand the tool functionality by initiating a specific application level fault to trigger optimisation algorithms

URL

DICE Fault Injection Tool(Paper)
DICE-Fault-Injection-Tool(Github Project)