Change Log

When What
April 9th, 2015 Donated by Jacob Swanson


Studies who have been using the data (in any form) are required to include the following reference:

  author = {Swanson, Jacob and Cohen, Myra B. and Dwyer, Matthew B. and Garvin, Brady J. and Firestone, Justin},
  title = {Beyond the Rainbow: Self-adaptive Failure Avoidance in Configurable Systems},
  booktitle = {Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering},
  series = {FSE 2014},
  year = {2014},
  isbn = {978-1-4503-3056-5},
  location = {Hong Kong, China},
  pages = {377--388},
  numpages = {12},
  url = {},
  doi = {10.1145/2635868.2635915},
  acmid = {2635915},
  publisher = {ACM},
  address = {New York, NY, USA},
  keywords = {Configurable Software, Self-Adaptive Software},

About the Data

Overview of Data

There are three dataset files supplemental to the study:

  1. FirefoxFM.xml The Firefox feature model (in XML)
  2. Normal test cases. These are the Mozmill test cases that we expected to pass.
  3. Seeded faulty test cases. These seven tests contain faults that we recreated based on real Firefox faults.

Paper Abstract

Self-adaptive software systems monitor their state and then adapt when certain conditions are met, guided by a global utility function. In prior work we developed algorithms and conducted a post-hoc analysis demonstrating the possibility of adapting to software failures by judiciously changing configurations. In this paper we present the REFRACT framework that realizes this idea in practice by building on the self-adaptive Rainbow architecture. REFRACT extends Rainbow with new components and algorithms targeting failure avoidance. We use REFRACT in a case study running four independently executing Firefox clients with 36 passing test cases and 7 seeded faults. The study show that workarounds for all but one of the seeded faults are found and the one that is not found never fails – it is guarded from failing by a related workaround. Moreover, REFRACT finds workarounds for eight configuration-related unseeded failures from tests that were expected to pass (and did under the default configuration). Finally, the data show that when a failure and its workaround are found, configuration guards prevent the failure from appearing again. In a simulation lasting 24 hours we see over 150 guard activations and no failures with workarounds remaining beyond 16 hours