Results 1 - 10
of
46
Compositional May-Must Program Analysis: Unleashing the Power of Alternation
"... Program analysis tools typically compute two types of information: (1) may information that is true of all program executions and is used to prove the absence of bugs in the program, and (2) must information that is true of some program executions and is used to prove the existence of bugs in the pr ..."
Abstract
-
Cited by 63 (15 self)
- Add to MetaCart
(Show Context)
Program analysis tools typically compute two types of information: (1) may information that is true of all program executions and is used to prove the absence of bugs in the program, and (2) must information that is true of some program executions and is used to prove the existence of bugs in the program. In this paper, we propose a new algorithm, dubbed SMASH, which computes both may and must information compositionally. At each procedure boundary, may and must information is represented and stored as may and must summaries, respectively. Those summaries are computed in a demand-driven manner and possibly using summaries of the opposite type. We have implemented SMASH using predicate abstraction (as in SLAM) for the may part and using dynamic test generation (as in DART) for the must part. Results of experiments with 69 Microsoft Windows Vista device drivers show that SMASH can significantly outperform may-only, must-only and non-compositional may-must algorithms. Indeed, our empirical results indicate that most complex code fragments in large programs are actually often either easy to prove irrelevant to the specific property of interest using may analysis or easy to traverse using directed testing. The fine-grained coupling and alternation of may (universal) and must (existential) summaries allows SMASH to easily navigate through these code fragments while traditional may-only, must-only or noncompositional may-must algorithms are stuck in their specific analyses. 1.
Program analysis as constraint solving
- In PLDI
, 2008
"... A constraint-based approach to invariant generation in programs translates a program into constraints that are solved using off-theshelf constraint solvers to yield desired program invariants. In this paper we show how the constraint-based approach can be used to model a wide spectrum of program ana ..."
Abstract
-
Cited by 54 (11 self)
- Add to MetaCart
(Show Context)
A constraint-based approach to invariant generation in programs translates a program into constraints that are solved using off-theshelf constraint solvers to yield desired program invariants. In this paper we show how the constraint-based approach can be used to model a wide spectrum of program analyses in an expressive domain containing disjunctions and conjunctions of linear inequalities. In particular, we show how to model the problem of context-sensitive interprocedural program verification. We also present the first constraint-based approach to weakest precondition and strongest postcondition inference. The constraints we generate are boolean combinations of quadratic inequalities over integer variables. We reduce these constraints to SAT formulae using bitvector modeling and use off-the-shelf SAT solvers to solve them. Furthermore, we present interesting applications of the above analyses, namely bounds analysis and generation of most-general counter-examples for both safety and termination properties. We also present encouraging preliminary experimental results demonstrating the feasibility of our technique on a variety of challenging examples.
Software Model Checking
"... Software model checking is the algorithmic analysis of programs to prove properties of their executions. It traces its roots to logic and theorem proving, both to provide the conceptual framework in which to formalize the fundamental questions and to provide algorithmic procedures for the analysis o ..."
Abstract
-
Cited by 52 (0 self)
- Add to MetaCart
Software model checking is the algorithmic analysis of programs to prove properties of their executions. It traces its roots to logic and theorem proving, both to provide the conceptual framework in which to formalize the fundamental questions and to provide algorithmic procedures for the analysis of logical questions. The undecidability theorem [Turing 1936] ruled out the possibility of a sound and complete algorithmic solution for any sufficiently powerful programming model, and even under restrictions (such as finite state spaces), the correctness problem remained computationally intractable. However, just because a problem is hard does not mean it never appears in practice. Also, just because the general problem is undecidable does not imply that specific instances of the problem will also be hard. As the complexity of software systems grew, so did the need for some reasoning mechanism about correct behavior. (While we focus here on analyzing the behavior of a program relative to given correctness specifications, the development of specification mechanisms happened in parallel, and merits a different survey.) Initially, the focus of program verification research was on manual reasoning, and
Detecting and Escaping Infinite Loops with Jolt
"... Abstract. Infinite loops can make applications unresponsive. Potential problems include lost work or output, denied access to application functionality, and a lack of responses to urgent events. We present Jolt, a novel system for dynamically detecting and escaping infinite loops. At the user’s requ ..."
Abstract
-
Cited by 23 (12 self)
- Add to MetaCart
(Show Context)
Abstract. Infinite loops can make applications unresponsive. Potential problems include lost work or output, denied access to application functionality, and a lack of responses to urgent events. We present Jolt, a novel system for dynamically detecting and escaping infinite loops. At the user’s request, Jolt attaches to an application to monitor its progress. Specifically, Jolt records the program state at the start of each loop iteration. If two consecutive loop iterations produce the same state, Jolt reports to the user that the application is in an infinite loop. At the user’s option, Jolt can then transfer control to a statement following the loop, thereby allowing the application to escape the infinite loop and ideally continue its productive execution. The immediate goal is to enable the application to execute long enough to save any pending work, finish any in-progress computations, or respond to any urgent events. We evaluated Jolt by applying it to detect and escape eight infinite loops in five benchmark applications. Jolt was able to detect seven of the eight infinite loops (the eighth changes the state on every iteration). We also evaluated the effect of escaping an infinite loop as an alternative to terminating the application. In all of our benchmark applications, escaping an infinite loop produced a more useful output than terminating the application. Finally, we evaluated how well escaping from an infinite loop approximated the correction that the developers later made to the application. For two out of our eight loops, escaping the infinite loop produced the same output as the corrected version of the application.
Automatically proving program termination
- In CAV
, 2007
"... Our goal in this book is to build sofware tools that automatically search for proofs of program termination in mathematical logic. However, before delving directly into strategies for automation, we must first introduce some notation and establish a basic foundation in the areas of program semantics ..."
Abstract
-
Cited by 23 (4 self)
- Add to MetaCart
Our goal in this book is to build sofware tools that automatically search for proofs of program termination in mathematical logic. However, before delving directly into strategies for automation, we must first introduce some notation and establish a basic foundation in the areas of program semantics, logic and set theory. We must also discuss how programs can be proved terminating using manual techniques. The concepts and notation introduced in this chapter will be used throughout the remainder of the book. 1.1 Program termination and well-founded relations For the purpose of this book it is convenient to think of the text of a computer program as representing a relation that specifies the possible transitions that the program can make between configurations during execution. We call this the program’s transition relation. Program executions can be thought of as traversals starting from a starting configuration and then moving from configuration to configuration as allowed by the transition relation. A program is called terminating if all the executions allowed by the transition relation are finite. We call a program non-terminating if the transition relation allows for at least one infinite execution. Treating programs as relations is conveinant for our purpose, as in this setting proving program termination is equivliant to proving the program’s transition relation well-founded — thus giving us access to the numerous well established techniques from mathematical logic used to establish well-foundedness. In the next few sections we define some notation, discuss our representation for program configurations, and give some basic results related 3 4
Solving existentially quantified Horn clauses
- IN CAV
, 2013
"... Temporal verification of universal (i.e., valid for all computation paths) properties of various kinds of programs, e.g., procedural, multi-threaded, or functional, can be reduced to finding solutions for equations in form of universally quantified Horn clauses extended with well-foundedness condit ..."
Abstract
-
Cited by 22 (5 self)
- Add to MetaCart
(Show Context)
Temporal verification of universal (i.e., valid for all computation paths) properties of various kinds of programs, e.g., procedural, multi-threaded, or functional, can be reduced to finding solutions for equations in form of universally quantified Horn clauses extended with well-foundedness conditions. Dealing with existential properties (e.g., whether there exists a particular computation path), however, requires solving forall-exists quantified Horn clauses, where the conclusion part of some clauses contains existentially quantified variables. For example, a deductive approach to CTL verification reduces to solving such clauses. In this paper we present a method for solving forall-exists quantified Horn clauses extended with well-foundedness conditions. Our method is based on a counterexample-guided abstraction refinement scheme to discover witnesses for existentially quantified variables. We also present an application of our solving method to automation of CTL verification of software, as well as its experimental evaluation.
Non-Termination Checking for Imperative Programs
"... Abstract. While termination checking tailored to real-world library code or frameworks has received ever-increasing attention during the last years, the complementary question of disproving termination properties as a means of debugging has largely been ignored so far. We present an approach to auto ..."
Abstract
-
Cited by 18 (0 self)
- Add to MetaCart
(Show Context)
Abstract. While termination checking tailored to real-world library code or frameworks has received ever-increasing attention during the last years, the complementary question of disproving termination properties as a means of debugging has largely been ignored so far. We present an approach to automatic non-termination checking that relates to termination checking in the same way as symbolic testing does to program verification. Our method is based on the automated generation of invariants that show that terminating states of a program are unreachable from certain initial states. Such initial states are identified using constraintsolving techniques. The method is fully implemented on top of a program verification system and available for download. We give an empirical evaluation of the approach using a collection of non-terminating example programs. 1
Reasoning about non-determinism in programs
"... Branching-time temporal logics (e.g. CTL, CTL ∗ , or the modal µ-calculus) allow us to ask sophisticated questions about the nondeterminism that appears in systems. Applications of this type of reasoning include planning, games, security analysis, disproving, precondition synthesis, environment synt ..."
Abstract
-
Cited by 13 (5 self)
- Add to MetaCart
(Show Context)
Branching-time temporal logics (e.g. CTL, CTL ∗ , or the modal µ-calculus) allow us to ask sophisticated questions about the nondeterminism that appears in systems. Applications of this type of reasoning include planning, games, security analysis, disproving, precondition synthesis, environment synthesis, etc. Unfortunately, existing automatic branching-time verification tools have limitions that have traditionally restricted their applicability (e.g. push-down systems only, universal path quantifiers only, etc). In this paper we introduce an automation strategy that lifts many of these previous restrictions. Our method works reliably for properties with non-trivial mixtures of universal and existential modal operators. Furthermore, our approach supports (possibly infinite-state) programs. The basis of our approach is the observation that existential reasoning can be reduced to universal reasoning if the system’s statespace is appropriately restricted. This restriction on the state-space must meet a constraint derived from recent work on proving nontermination. The observation leads to a new route for implementation based on existing tools. To demonstrate the practical viability of our approach, we report on the results applying our preliminary implementation to a set of benchmarks drawn from the Windows operating system, the PostgreSQL database server, Soft-Updates patching system, as well as other hand-crafted examples. 1.
Bolt: on-demand infinite loop escape in unmodified binaries
- In OOPSLA
, 2012
"... We present Bolt, a novel system for escaping from infinite and long-running loops. Directed by a user, Bolt can attach to a running process and determine if the program is executing an infinite loop. If so, Bolt can deploy multiple strategies to escape the loop, restore the responsiveness of the pro ..."
Abstract
-
Cited by 12 (11 self)
- Add to MetaCart
(Show Context)
We present Bolt, a novel system for escaping from infinite and long-running loops. Directed by a user, Bolt can attach to a running process and determine if the program is executing an infinite loop. If so, Bolt can deploy multiple strategies to escape the loop, restore the responsiveness of the program, and enable the program to deliver useful output. Bolt operates on stripped x86 and x64 binaries, dynamically attaches and detaches to and from the program as needed, and dynamically detects loops and creates program state checkpoints to enable exploration of different escape strategies. Bolt can detect and escape from loops in off-theshelf software, without available source code, and with no overhead in standard production use.
Automated Detection of Non-Termination and NullPointerExceptions for Java Bytecode ⋆
"... Abstract. Recently, we developed an approach for automated termination proofs of Java Bytecode (JBC), which is based on constructing and analyzing termination graphs. These graphs represent all possible program executions in a finite way. In this paper, we show that this approach can also be used to ..."
Abstract
-
Cited by 12 (6 self)
- Add to MetaCart
(Show Context)
Abstract. Recently, we developed an approach for automated termination proofs of Java Bytecode (JBC), which is based on constructing and analyzing termination graphs. These graphs represent all possible program executions in a finite way. In this paper, we show that this approach can also be used to detect non-termination or NullPointerExceptions. Our approach automatically generates witnesses, i.e., calling the program with these witness arguments indeed leads to non-termination resp. to a NullPointerException. Thus, we never obtain “false positives”. We implemented our results in the termination prover AProVE and provide experimental evidence for the power of our approach. 1
