Reachability analysis for annotated code

Janota, Mikoláš; Grigore, Radu; Moskal, Michał

doi:10.1145/1292316.1292319

Cited by 16 publications

(6 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The problem of detecting inconsistent code has been studied quite extensively in the literature [6,12,13,19,21,24,24,34]. Note that many of these papers use slightly different terminology such as deviant code [13], doomed code [21], infeasible code [2], and fatal code [34].…”

Section: Related Workmentioning

confidence: 99%

Explaining inconsistent code

Schäf¹,

Schwartz-Narbonne

Wies

2013

Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering

View full text Add to dashboard Cite

A code fragment is inconsistent if it is not part of any normally terminating execution. Examples of such inconsistencies include code that is unreachable, code that always fails due to a run-time error, and code that makes conflicting assumptions about the program state. In this paper, we consider the problem of automatically explaining inconsistent code. This problem is difficult because traditional fault localization techniques do not apply. Our solution relies on a novel algorithm that takes an infeasible code fragment as input and generates a so-called error invariant automaton. The error invariant automaton is an abstraction of the input code fragment that only mentions program statements and facts that are relevant for understanding the cause of the inconsistency. We conducted a preliminary usability study which demonstrated that error invariant automata can help programmers better understand inconsistencies in code taken from real-world programs. In particular, access to an error invariant automata tripled the speed at which programmers could diagnose the cause of a code inconsistency.

show abstract

Section: Related Workmentioning

confidence: 99%

Explaining inconsistent code

Schäf¹,

Schwartz-Narbonne

Wies

2013

Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering

View full text Add to dashboard Cite

show abstract

“…Recently, static verification techniques are being used to prove the existence of infeasible code [16,13,4,21]. These techniques prove the existence of statements that do not occur on any feasible (complete) control-flow path in a program.…”

Section: Introductionmentioning

confidence: 99%

“…Janota et al [16] present an approach to detect unreachable code in the presence of logic specifications. They only focus on the subset of infeasible code that is not forward reachable.…”

Section: Introductionmentioning

confidence: 99%

Reconstructing Paths for Reachable Code

Arlt¹,

Liu²,

Schäf³

2013

Formal Methods and Software Engineering

View full text Add to dashboard Cite

Abstract. Infeasible code has proved to be an interesting target for static analysis. It allows modular and scalable analysis, and at the same time, can be implemented with a close-to-zero rate of false warnings. The challenge for an infeasible code detection algorithm is to find executions that cover all statements with feasible executions as fast as possible. The remaining statements are infeasible code. In this paper we propose a new encoding of programs into first-order logic formulas that allows us to query the non-existence of feasible executions of a program, and, to reconstruct a feasible path from counterexamples produced for this query. We use these paths to develop a path-cover algorithm based on blocking clauses. We evaluate our approach using several real-world applications and show that our new prover-friendly encoding yields a significant speed-up over existing approaches.

show abstract

“…The effect of having one error mask others is particularly acute for ESC/Java2 (even more so than in ordinary compilers) thus making effective the more resilient, though less powerful, complementary verification capabilities of other techniques such as those implemented in JML4 (and recently added to ESC/Java2 [17]). Our preliminary use of JML4 has demonstrated that, e.g., nullity type errors once fixed allow ESC to push further its analysis, helping expose yet more bugs in code and specifications, which leads to uncovering further nullity type errors, etc.…”

Section: Introductionmentioning

confidence: 99%

An integrated verification environment for JML

Chalin

James

Karabotsos

2007

Proceedings of the 2007 Conference on Specification and Verification of Component-Based Systems 6th Joint Meeting of the Europe

View full text Add to dashboard Cite

Tool support for the Java Modeling Language (JML) is a very pressing problem. A main issue with current tools is their architecture: the cost of keeping up with the evolution of Java is prohibitively high: e.g., almost three years following its release, Java 5 has yet to be fully supported. This paper presents the architecture of JML4, an Integrated Verification Environment (IVE) for JML that builds upon Eclipse's support for Java, enhancing it with Extended Static Checking (ESC), an early form of Runtime Assertion Checking (RAC) and JML's non-null type system. Early results indicate that the synergy of complementary verification techniques (being made available within a single tool) can help developers be more effective; we demonstrate new bugs uncovered in JML annotated Java source-like ESC/Java2-which is routinely verified using first generation JML tools.

show abstract

Reachability analysis for annotated code

Cited by 16 publications

References 24 publications

Explaining inconsistent code

Explaining inconsistent code

Reconstructing Paths for Reachable Code

An integrated verification environment for JML

Contact Info

Product

Resources

About