Near-Omniscient Debugging for Java Using Size-Limited Execution Trace

Shimari, Kazumasa; Ishio, Takashi; Kanda, Takahiro; Inoue, Katsuro

doi:10.1109/icsme.2019.00068

Cited by 11 publications

(4 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…DIDIFFFF runs two versions of a program and illustrates the difference between the values assigned to program variables in a web interface. DIDIFFFF uses SELOGGER [27] to record all the values each variable of a program holds during an execution. Using these values, DIDIFFFF creates two lists of values for each variable access that is not part of the code change.…”

Section: Baselinementioning

confidence: 99%

“…Different tools have been created that fully or partially implement this concept of omniscient debuggers [32]. The state-of-the-art omniscient debugger is introduced by Shimari et al [27], [33]. They introduce SELOGGER, which records events, such as method entry, method exit, return values, and reading or writing a value into a variable.…”

Section: A Collecting Execution Datamentioning

confidence: 99%

See 1 more Smart Citation

Augmenting Diffs With Runtime Information

Etemadi,

Sharma,

Madeiral

et al. 2023

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

show abstract

Section: Baselinementioning

confidence: 99%

Section: A Collecting Execution Datamentioning

confidence: 99%

Augmenting Diffs With Runtime Information

Etemadi,

Sharma,

Madeiral

et al. 2023

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…It is possible to see work in a variety of software engineering research domains as an attempt to avoid or lesser the chance of events occurring during the evolution of software that is already in production (Huang et al, 2017). By improving While some work focuses on reducing the time it took to mitigate events as they occur, other efforts focus on needed to monitor the following software systems and evaluate system behavior and status (Shimari et al, 2019). Reducing time to mitigation and preventing problems would both benefit from engineers having a richer grasp of events and incident response procedures as they currently occur.…”

Section: Introductionmentioning

confidence: 99%

Failures and Repairs: An Examination of Software System Failure

Rahman,

Arshid,

Ayaz

et al. 2024

BBE

View full text Add to dashboard Cite

The central theme of the article is to provide a better knowledge of software system failures and how to assure, maintain, and provide the support software systems that are in production. It includes the results of our search study. We conducted a qualitative analysis of thirty cases: fifteen from public incident reports and fifteen from in-depth interviews with engineers. Understanding and classifying failures as well as their identification, investigation, and mitigation were the main goals of our study. Furthermore, we obtained important analytical insights that are pertinent to the condition of practice as it is now and related problems. It is common for engineers to be unaware of the scaling limitations of the systems they support until those limits are exceeded, and failures have the potential to cascade across a system and cause catastrophic outages.We argue that the difficulties we've discovered may lead to changes in how systems are designed and supported.

show abstract

“…Work in multiple software engineering research areas can be seen as (at least partially) aiming to reduce the likelihood of incidents occurring as software that is already in production is evolved (see for example work on defect detection and prediction [22]). Other work aims to reduce the time it takes to mitigate incidents when they do occur, often focusing on improving the way we design the infrastructure tools used to monitor software systems and investigate system state and behavior (see for example work on debugging and execution traces [35]). Both the goal of preventing incidents and the goal of reducing time to mitigation will benefit from a deeper understanding of both incidents and incident response processes, as they are experienced by engineers today.…”

Section: Introductionmentioning

confidence: 99%

Failures and Fixes: A Study of Software System Incident Response

Sillito¹,

Kutomi²

2020

Preprint

View full text Add to dashboard Cite

This paper presents the results of a research study related to software system failures, with the goal of understanding how we might better evolve, maintain and support software systems in production. We have qualitatively analyzed thirty incidents: fifteen collected through in depth interviews with engineers, and fifteen sampled from publicly published incident reports (generally produced as part of postmortem reviews). Our analysis focused on understanding and categorizing how failures occurred, and how they were detected, investigated and mitigated. We also captured analytic insights related to the current state of the practice and associated challenges in the form of 11 key observations. For example, we observed that failures can cascade through a system leading to major outages; and that often engineers do not understand the scaling limits of systems they are supporting until those limits are exceeded. We argue that the challenges we have identified can lead to improvements to how systems are engineered and supported.

show abstract

Near-Omniscient Debugging for Java Using Size-Limited Execution Trace

Cited by 11 publications

References 17 publications

Augmenting Diffs With Runtime Information

Augmenting Diffs With Runtime Information

Failures and Repairs: An Examination of Software System Failure

Failures and Fixes: A Study of Software System Incident Response

Contact Info

Product

Resources

About