Bugs as deviant behavior: a general approach to inferring errors in systems code

By Dawson R. Engler, David Yu Chen, Andy Chou. 2001

839 citations recorded by the source corpus.

Subfields: Information Systems, Software, Program Analysis & Verification

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Information Systems

In Software

In Program Analysis & Verification

Citations in the corpus

A Survey of Machine Learning for Big Code and Naturalness (2017, background): “l[153]useanLMofsourcecodetogenerateinputforfuzztestingbrowsers. Not all anomalous behavior is a bug (it may simply be rare behavior), but anomalous behavior in often executed code almost certainly is [56]. Thus, probabilistic models of source code seem a natural ﬁt for ﬁnding defective code. They ha”
DeepBugs: a learning approach to name-based bug detection (2018, methodology): “Our approach differs from existing bug detectors that identify bugs as anomalies in a corpus of code [Engler et al. 2001; Hangal and Lam 2002; Monperrus et al. 2010].”
Fault localization with nearest neighbor queries (2003, background): “[7] discover code structure rules in programs similar to the subject program, and then check for violations of those rules.”
Software Vulnerability Detection Using Deep Neural Networks: A Survey (2020, methodology): “Static techniques, such as rule/template-based analysis [16], [29], [113], code similarity detection [42], [45], and symbolic execution [13], [83], [106], mainly rely on the analysis of source code, but often suffer from high false positives [56].”
Debugging in the (very) large: ten years of implementation and experience (2009, methodology): “The best techniques for isolating bugs are systems based on static analysis and model checking [2, 3, 6, 11].”
Understanding and detecting real-world performance bugs (2012, methodology): “Tools that automatically infer functional correctness rules [13, 30, 33] may not be suitable for efficiency rules, because rule violations are not rare, as shown in Table 4.”
Ownership types for safe programming: preventing data races and deadlocks (2002, background): “[21] assumes bugs to be deviant behavior to statically extract and check correctness conditions that a system must obey without requiring programmer annotations.”
RacerX: effective, static detection of race conditions and deadlocks (2003, methodology): “We use belief analysis [14] to distinguish when a semaphore is being used as a lock as opposed to a signal-wait semaphore.”
HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity (2010, background): “These systems are designed to uncover bugs in the source code [10], [15]; prevent the bug from being exploited [2]; reason about the safety of one facet of the software [9]; or demonstrate the absence of some kind of bugs [17].”
Understanding BGP misconfiguration (2002, background): “Checking selfconsistency has already proved to be highly effective for systems code [11], where high-level safe languages are often eschewed in favor of more flexible, low-level constructs.”
Mining specifications (2002, methodology): “A verification tool that uses the specification to examine all program paths (such as Bebop [2] or xgcc [10]) could then find the rare bug.”
Emergent, crowd-scale programming practice in the IDE (2014, neutral): “Much work has focused on tools for static and dynamic analysis [2, 10].”
Bugram: Bug detection with n-gram language models (2016, background): “Rule-based bug detection approaches infer likely programming rules from source code [1,4,6,8,23,24, 42, 45, 46, 54], version histories [4, 19, 53], and source code comments [43,44].”
Graph-based mining of multiple object usage patterns (2009, background): “[10]’s approach is also limited to patterns of pairs of method calls.”
Following Devil's Footprints: Cross-Platform Analysis of Potentially Harmful Libraries on Android and iOS (2016, background): “Invariants are widely used in ﬁnding a program’s vulnerabilities [21], [24], [61], [25], which are typically discovered through dynamically analyzing the program [21].”