Producing Short Counterexamples Using “Crucial Events”

Kashyap, Sujatha; Garg, Vijay K.

doi:10.1007/978-3-540-70545-1_47

Cited by 9 publications

(4 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The major difference between these works and ours is that they focus on explaining one or more given counterexamples, while our objective to classify the set of all counterexamples into distinct classes. Our work is also related and complementary to [8], which focuses on generating short counterexamples. We take a different approach by focusing on generating minimal trace constraints, each of which characterize a set of counterexamples.…”

Section: Related Workmentioning

confidence: 99%

Counterexample Classification

Vick¹,

Kang²,

Tripakis³

2021

Preprint

View full text Add to dashboard Cite

In model checking, when a given model fails to satisfy the desired specification, a typical model checker provides a counterexample that illustrates how the violation occurs. In general, there exist many diverse counterexamples that exhibit distinct violating behaviors, which the user may wish to examine before deciding how to repair the model. Unfortunately, obtaining this information is challenging in existing model checkers since (1) the number of counterexamples may be too large to enumerate one by one, and (2) many of these counterexamples are redundant, in that they describe the same type of violating behavior. In this paper, we propose a technique called counterexample classification. The goal of classification is to partition the space of all counterexamples into a finite set of counterexample classes, each of which describes a distinct type of violating behavior for the given specification. These classes are then presented as a summary of possible violating behaviors in the system, freeing the user from manually having to inspect or analyze numerous counterexamples to extract the same information. We have implemented a prototype of our technique on top of an existing formal modeling and verification tool, the Alloy Analyzer, and evaluated the effectiveness of the technique on case studies involving the well-known Needham-Schroeder protocol with promising results.

show abstract

Section: Related Workmentioning

confidence: 99%

Counterexample Classification

Vick¹,

Kang²,

Tripakis³

2021

Preprint

View full text Add to dashboard Cite

show abstract

“…root causes) from concurrent error traces. In [30], the authors focus on shortening counterexamples in message-passing programs to a set of "crucial events" that are both necessary and sufficient to reach the bug. In [27], the authors introduce a heuristic to simplify concurrent error traces by reducing the number of context-switches.…”

Section: Related Workmentioning

confidence: 99%

Root Causing Linearizability Violations

Çirişci

Enea

Farzan

et al. 2020

Computer Aided Verification

View full text Add to dashboard Cite

Linearizability is the de facto correctness criterion for concurrent data type implementations. Violation of linearizability is witnessed by an error trace in which the outputs of individual operations do not match those of a sequential execution of the same operations. Extensive work has been done in discovering linearizability violations, but little work has been done in trying to provide useful hints to the programmer when a violation is discovered by a tester tool. In this paper, we propose an approach that identifies the root causes of linearizability errors in the form of code blocks whose atomicity is required to restore linearizability. The key insight of this paper is that the problem can be reduced to a simpler algorithmic problem of identifying minimal root causes of conflict serializability violation in an error trace combined with a heuristic for identifying which of these are more likely to be the true root cause of non-linearizability. We propose theoretical results outlining this reduction, and an algorithm to solve the simpler problem. We have implemented our approach and carried out several experiments on realistic concurrent data types demonstrating its efficiency.

show abstract

“…Other static approaches for simplifying and summarizing concurrent error traces include [10], [11], [12], and [15]. In [10], an SMT solver and model enumeration is used to derive a symbolic representation of all reorderings of a given trace that violate a safety property, which is then used to explain the bug.…”

Section: Related Workmentioning

confidence: 99%

Error Invariants for Concurrent Traces

Holzer

Schwartz-Narbonne

Befrouei

et al. 2016

FM 2016: Formal Methods

View full text Add to dashboard Cite

Error invariants are assertions that over-approximate the reachable program states at a given position in an error trace while only capturing states that will still lead to failure if execution of the trace is continued from that position. Such assertions reflect the effect of statements that are involved in the root cause of an error and its propagation, enabling slicing of statements that do not contribute to the error. Previous work on error invariants focused on sequential programs. We generalize error invariants to concurrent traces by augmenting them with additional information about hazards such as write-after-write events, which are often involved in race conditions and atomicity violations. By providing the option to include varying levels of details in error invariants-such as hazards and branching information-our approach allows the programmer to systematically analyze individual aspects of an error trace. We have implemented a hazard-sensitive slicing tool for concurrent traces based on error invariants and evaluated it on benchmarks covering a broad range of real-world concurrency bugs. Hazard-sensitive slicing significantly reduced the length of the considered traces and still maintained the root causes of the concurrency bugs.

show abstract

Producing Short Counterexamples Using “Crucial Events”

Cited by 9 publications

References 17 publications

Counterexample Classification

Counterexample Classification

Root Causing Linearizability Violations

Error Invariants for Concurrent Traces

Contact Info

Product

Resources

About