A few billion lines of code later

By A. Bessey, Ken Block, B. Chelf, Andy Chou, B. Fulton, Seth Hallem, Charles-Henri Gros, Asya Kamsky, Scott McPeak, Dawson R. Engler. 2010

698 citations recorded by the source corpus.

Subfields: Artificial Intelligence, Information Systems, 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 Artificial Intelligence

In Information Systems

In Program Analysis & Verification

Citations in the corpus

Finding Likely Errors with Bayesian Specifications (2017, methodology): “Over the years, research on automated bug finding in programs has had many real-world successes (Bessey et al. 2010; Ball et al. 2011).”
S2E: a platform for in-vivo multi-path analysis of software systems (2011, background): “various vendors; access to all corresponding source code is rarely feasible and, even when source code is available, building the code exactly as in the shipped software product is difficult [5].”
DiverseVul: A New Vulnerable Source Code Dataset for Deep Learning Based Vulnerability Detection (2023, background): “A project might contain tens of thousands of functions, and this false positive rate corresponds to hundreds of false positives, which is more than most analysts are likely to be willing to wade through [1].”
Hoppity: Learning Graph Transformations to Detect and Fix Bugs in Programs (2020, neutral): “Coverity (Bessey et al., 2010), SonarQube, and Clang Static Analyzer check for semantic inconsistencies in code based on more sophisticated path analyses.”
SVF: interprocedural static value-flow analysis in LLVM (2016, methodology): “Some industry static analysis tools that use program dependence analysis include Coverity [6] from Synopsys, Parfait [13] from Oracle, and SLAM (built on top of Microsoft’s in-house compiler) [5].”
Is the cure worse than the disease? overfitting in automated program repair (2015, background): “Since legacy codebases often are often idiosyncratic to the point of not adhering to the speciﬁcations of their host language [9], it might not be possible even to add contracts to such projects.”
Cross-architecture bug search in binary executables (2015, background): “Similarly, COVERITY [4] uses static analysis to reveal potential memory corruption vulnerabilities or data races; however, it fails to verify whether all preconditions for exploitation are actually met, and also does not cover all bug classes.”
Software Vulnerability Analysis and Discovery Using Machine-Learning and Data-Mining Techniques (2017, methodology): “Earlier works in this category (such as Engler et al. (2001) and Livshits and Zimmermann (2005)) are more focused on the order of method-calls as API-usage rules and report poor results. More recent studies (such as Chang et al. (2008) and Yamaguchi et al. (2013)) utilize program elements and the fl”
Decoding the Representation of Code in the Brain: An fMRI Study of Code Review and Expertise (2017, background): “For example, many developers avoid using tools with high false positive rates [35], but humans and tools may not agree on what is a false positive [4], [8].”
Towards Automated Dynamic Analysis for Linux-based Embedded Firmware (2016, background): “Namely, either the analysis is very generic and produces a large number of false positives [5], or the analysis is too specific and results in many false negatives.”
Why don't software developers use static analysis tools to find bugs? (2013, background): “Our research aims to understand why software developers are not using static analysis tools and how current tools could be improved to increase usage based on developer feedback.”