DOCSLIB.ORG

Finding Real Bugs in Big Programs with Incorrectness Logic 2 This Is a Draft Paper of August 2021 Describing Work That Has Not Yet Been Published

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Finding Real Bugs in Big Programs with Incorrectness Logic 2 This Is a Draft Paper of August 2021 Describing Work That Has Not Yet Been Published 1 Finding Real Bugs in Big Programs with Incorrectness Logic 2 This is a draft paper of August 2021 describing work that has not yet been published. 3 4 QUANG LOC LE, University College London and Facebook, UK 5 AZALEA RAAD, Imperial College London and Facebook, UK 6 JULES VILLARD, Facebook, UK 7 Facebook, UK 8 JOSH BERDINE, 9 DEREK DREYER, MPI-SWS, Germany 10 PETER W. O’HEARN, Facebook and University College London, UK 11 Recently, Incorrectness Logic (IL) has been advanced as a logical theory for proving the presence of bugs. Its 12 proof theory supports a compositional approach to reasoning which mirrors the compositionality of Hoare 13 logic, where knowledge that a bug exists can be inferred from local properties established independently for 14 program parts. This promise of the compositionality of IL for bug catching is, however, so far unrealized: 15 reasoning about bugs was done by hand, in a merely suggestive way, in the early work. 16 In this paper, we take a step towards realizing the promise of the compositional reasoning principles of IL 17 as a foundation for practical program analysis. Specifically, we develop Pulse-X, a new, automatic program 18 analysis for memory bugs based on ISL, a recent synthesis of IL and separation logic. To investigate the effectiveness of Pulse-X, we compare it to Infer, a related, widely used analyzer which has proven useful in 19 industrial engineering practice, demonstrating how Pulse-X is competitive for speed and, when zooming in on 20 a particular large program (OpenSSL), finds more true bugs with fewer false positives. Using Pulse-X, we have 21 also found 15 new real bugs in OpenSSL, which we have reported to OpenSSL maintainers and have since 22 been fixed. 23 24 25 1 INTRODUCTION 26 Incorrectness Logic (IL)[O’Hearn 2019] describes principles for reasoning about the presence of 27 bugs as a dual to those of Hoare’s logic (HL) for reasoning about their absence. As well as being able 28 to describe existing bug catching approaches, including traditional testing and symbolic execution, 29 the proof theory of IL mirrors the compositionality of HL, where proofs of compound programs are 30 built from (proven) specifications of its parts. In a retrospective on 50 years of Hoare logic, Apt and 31 Olderog[2019] identify this compositionality as the principal reason for HL’s remarkable influence. 32 In this paper we take steps towards realising the potential of the IL compositionality, by devel- 33 oping an automatic program analyser, Pulse-X, which we apply to real programs. Our analyser 34 is closely inspired by the Infer tool which is in deployment at Facebook, Amazon, Microsoft and 35 other companies. In particular, Pulse-X adopts Infer’s approach to compositionality based on the 36 biabductive proof principle [Calcagno et al. 2011]. However, rather than building on classic sepa- 37 ration logic [O’Hearn et al. 2001] as Infer did, Pulse-X builds instead on the recent Incorrectness 38 Separation Logic (ISL,[Raad et al. 2020]); and rather than reporting bugs based on failing to prove 39 their absence, Pulse-X instead reports bugs based on positive proofs of their presence. 40 41 Program Analysis Context. Before describing our results, we recall some of the relevant pro- 42 gram analysis context. The theory of static program analysis has traditionally most often adopted a 43 global program perspective: analyses assume they are given the whole program to be analysed, 44 compute an approximation (usually an over-approximation) of the program runs, and then use this 45 information to issue bug reports [Cousot and Cousot 1977; Rival and Yi 2020]. Although there are 46 notable exceptions (e.g., [Cousot 2001]), much less attention has been paid to the foundations of 47 compositional static analysis. A compositional analysis is one in which each part of the program is 48 analysed locally—i.e., independently of the global program context in which it is used. The analysis 49 , Vol. 1, No. 1, Article . Publication date: August 2021. 2 Quang Loc Le, Azalea Raad, Jules Villard, Josh Berdine, Derek Dreyer, and Peter W.O’Hearn 50 result of a composite program is then computed directly from the analysis results of its constituent 51 parts [Calcagno et al. 2011]. 52 In recent CACM articles, industrial developers of static analyses at Facebook [Distefano et al. 53 2019] and Google [Sadowski et al. 2018] described several concrete advantages of compositional 54 static analyses in practical deployments, the overarching one being that compositionality enables 55 analyses to be usefully integrated into the code review process. According to the Facebook article, 56 industrial codebases evolve at such a high velocity that, for a bug-finding analysis to be deployable 57 as part of a code review process, it must execute in minutes and not hours; thus, any analysis 58 that requires traversal of an entire large program would likely be too slow. By contrast, since 59 compositional analyses work locally on code snippets rather than globally on whole programs, they 60 can be run quickly (in minutes) on diffs (snippets of code that change as part of a pull request). This 61 agility makes it possible for compositional analyses to be run automatically as part of continuous 62 integration (CI) systems and provide timely information to developers performing code review. 63 The Problem of Compositional Bug Reporting. One of the central problems in developing 64 static analyses—particularly compositional analyses that are deployed automatically as part of 65 CI—is figuring out when to report bugs to developers. This is difficult for several reasons. 66 First, the fast, compositional static analyses deployed in CI usually do not enjoy a “soundness for 67 bug-catching” theorem. If they are sound for correctness (proving the absence of bugs) then any 68 alarm they report will be the result of a failure to prove the program correct, and not of having 69 found a bug with certainty. On the other hand, static analysis tools that are sound for incorrectness 70 (proving the presence of bugs) have been developed, e.g., symbolic execution, but they usually 71 work in a whole-program fashion and (thus far) have been too slow for CI on large codebases. 72 Second, there is the even more fundamental question of what constitutes a “bug”. For global 73 analyses, we can appeal to the classic distinction between true positives and false positives: a 74 bug report is deemed a true positive if the bug can be exercised in some concrete execution of 75 the program starting from a main() function or other specified entry points, and is otherwise 76 deemed a false positive. On the other hand, compositional analyses only examine code snippets, 77 not whole programs, so they must report bugs based only on local information about a snippet, 78 without knowing the global program context in which it is used. In some cases such as libraries, an 79 enveloping “whole program” simply does not exist. In the absence of such contextual information, 80 however, it is not clear how to even define whether a bug reported by a compositional analysis isa 81 true positive or not. 82 For example, a compositional analysis might deduce that a function foo is safe to execute 83 when passed a nonzero argument, but that it will incur a memory safety error (e.g., null-pointer- 84 dereference) when passed zero (0). Without knowing the calling contexts of foo, does this “bug” 85 count as a true positive or not, and should it be reported? 86 In industrially deployed compositional analysis tools (such as those presented in the aforemen- 87 tioned CACM articles), the choice of when to report bugs is thus typically implemented using 88 heuristics, which are refined over time based on empirical evaluation of developer feedback onthe 89 bug reports produced by the tool. Moreover, the success of these tools is measured not in “true 90 positive rate” or “false positive rate” but rather in fix rate, namely the proportion of reported bugs 91 fixed by developers.1 Fix rate is a useful empirical metric of the analysis effectiveness, but it leaves 92 open a natural research question: 93 94 Can we develop useful compositional bug-finding tools, and characterise their effectiveness, 95 in a more formally rigorous way? 96 1The Google article [Sadowski et al. 2018] uses the term “effective false positive” for a report a developer does not fix,but 97 this should not be confused with the established objective concept of false positive as a spurious bug claim. 98 , Vol. 1, No. 1, Article . Publication date: August 2021. Finding Real Bugs in Big Programs with Incorrectness Logic 3 99 Contributions. In this paper, we make a significant step forward in answering the above ques- 100 tion. Specifically, we develop a compositional program analysis that is similar in spirit and deploya- 101 bility to existing, empirically effective analyses, but that (unlike those analyses) is also backed by 102 rigorous foundations concerning the abstractions it computes and the bugs it reports. 103 We take as our starting point the original foundation of Infer [Calcagno et al. 2011], one of 104 the analyses described in the Facebook paper. Infer’s use of biabduction provides a powerful tech- 105 nique for inferring compositional specifications for memory-manipulating procedures. However, 106 as O’Hearn[2019] has noted, there is a fundamental mismatch between the logical foundation 107 of Infer and its practical deployment. On the one hand, the theory of Infer is based on separation 108 logic [O’Hearn et al.
Load more

Recommended publications
  • The Scrabble Player's Handbook Is Available for Free Download At
    The Scrabble Player's Handbook is available for free download at www.scrabbleplayershandbook.com 1 Contents Introduction 3 Meet The Team 5 What's Different About Competitive Scrabble? 10 How To Play Good Scrabble 11 The Words 14 What Is Scrabble? 16 Scoring Well 21 Understanding Rack Leaves 32 Word Learning 35 The First Move 46 Tile Tracking 50 Time Management 54 Exchanging 58 Phoneys 64 Set-Ups 65 Open and Closed Boards 68 The Endgame 75 Playing Style 85 How To Play Amazing Scrabble 94 The Luck Element 98 The Game Behind The Game 99 Starting Out in Competitive Play 101 Quackle 103 Zyzzyva 109 Internet Scrabble Club 115 Aerolith 117 Scrabble by Phone 119 Books 121 Scrabble Variants 123 Scrabble Around The World 125 Playing Equipment 127 Glossary 128 Appendix 133 Rules Governing Word Inclusion 133 Two-letter words 137 Three-letter words 140 SCRABBLE® is a registered trademark. All intellectual property rights in and to the game are owned in the U.S.A. by Hasbro Inc., in Canada by Hasbro Canada Inc. and throughout the rest of the world by J.W. Spear & Sons Ltd. of Maidenhead SL6 4UB, England, a subsidiary of Mattel Inc. Mattel and Spear are not affiliated with Hasbro or Hasbro Canada. The Scrabble Player's Handbook is available free of charge. There is no copyright on the contents and readers are encouraged to distribute the book in PDF or printed form to all who would benefit from it. Please respect our work by retaining the footer on every page and by refraining from reproducing any part of this book for financial gain.
    [Show full text]
  • Automated Program Transformation for Improving Software Quality
    Automated Program Transformation for Improving Software Quality Rijnard van Tonder CMU-ISR-19-101 October 2019 Institute for Software Research School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Claire Le Goues, Chair Christian Kästner Jan Hoffmann Manuel Fähndrich, Facebook, Inc. Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Software Engineering. Copyright 2019 Rijnard van Tonder This work is partially supported under National Science Foundation grant numbers CCF-1750116 and CCF-1563797, and a Facebook Testing and Verification research award. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring corporation, institution, the U.S. government, or any other entity. Keywords: syntax, transformation, parsers, rewriting, crash bucketing, fuzzing, bug triage, program transformation, automated bug fixing, automated program repair, separation logic, static analysis, program analysis Abstract Software bugs are not going away. Millions of dollars and thousands of developer-hours are spent finding bugs, debugging the root cause, writing a patch, and reviewing fixes. Automated techniques like static analysis and dynamic fuzz testing have a proven track record for cutting costs and improving software quality. More recently, advances in automated program repair have matured and see nascent adoption in industry. Despite the value of these approaches, automated techniques do not come for free: they must approximate, both theoretically and in the interest of practicality. For example, static analyzers suffer false positives, and automatically produced patches may be insufficiently precise to fix a bug.
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [Show full text]
  • Racerd: Compositional Static Race Detection
    RacerD: Compositional Static Race Detection SAM BLACKSHEAR, Facebook, USA NIKOS GOROGIANNIS, Facebook, UK and Middlesex University London, UK PETER W. O’HEARN, Facebook, UK and University College London, UK ILYA SERGEY∗, Yale-NUS College, Singapore and University College London, UK Automatic static detection of data races is one of the most basic problems in reasoning about concurrency. We present RacerD—a static program analysis for detecting data races in Java programs which is fast, can scale to large code, and has proven effective in an industrial software engineering scenario. To our knowledge, RacerD is the first inter-procedural, compositional data race detector which has been empirically shownto have non-trivial precision and impact. Due to its compositionality, it can analyze code changes quickly, and this allows it to perform continuous reasoning about a large, rapidly changing codebase as part of deployment within a continuous integration ecosystem. In contrast to previous static race detectors, its design favors reporting high-confidence bugs over ensuring their absence. RacerD has been in deployment for over a year at Facebook, where it has flagged over 2500 issues that have been fixed by developers before reaching production. It has been important in enabling the development of new code as well as fixing old code: it helped support the conversion of part of the main Facebook Android app from a single-threaded to a multi-threaded architecture. In this paper we describe RacerD’s design, implementation, deployment and impact. CCS Concepts: • Theory of computation → Program analysis; • Software and its engineering → Concurrent programming structures; Additional Key Words and Phrases: Concurrency, Static Analysis, Race Freedom ACM Reference Format: Sam Blackshear, Nikos Gorogiannis, Peter W.
    [Show full text]
  • Developing a Pedagogical Framework for Gaming Literacy in the Multimodal Composition Classroom
    TOOLS OF PLAY: DEVELOPING A PEDAGOGICAL FRAMEWORK FOR GAMING LITERACY IN THE MULTIMODAL COMPOSITION CLASSROOM Tina Lynn Arduini A Dissertation Submitted to the Graduate College of Bowling Green State University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2016 Committee: Kristine Blair, Advisor Gi Yun, Graduate Faculty Representative Lee Nickoson Sue Carter Wood ii ABSTRACT Kristine Blair, Advisor Since the publication of James Paul Gee’s (2003) seminal text What Video Games Have to Teach us About Learning and Literacy, scholars in the field of rhetoric and writing have been looking at the ways video games have made an impact on modern literacies. Paralleling this research, rhetoric and writing teacher-scholars have also been exploring the benefits to teaching multimodal composition skills to their students. My dissertation examines the intersections of these two related fields of study in order to help construct a pedagogical framework that utilizes gaming literacies in the multimodal composition classroom. Using the gaming literacy narratives of three student gamers at a rural Midwestern university, I address the following research questions: How do students acquire gaming literacy? What kinds of multimodal skills are acquired through gaming literacy? What does one’s gaming literacy narrative reveal about his or her literate practices? The answers to these questions help to inform my approach to the more pedagogically-driven research question: How can gaming literacy be effectively used in the multimodal composition classroom? My findings are influenced by technofeminist research methodologies so that I explore not only the role that video games have played upon my research participants but also the social adaptations that the participants have exerted over their gaming experiences.
    [Show full text]
  • Static Analysis, Race Freedom ACM Reference Format: Sam Blackshear, Nikos Gorogiannis, Peter W
    RacerD: Compositional Static Race Detection SAM BLACKSHEAR, Facebook, USA NIKOS GOROGIANNIS, Facebook, UK and Middlesex University London, UK PETER W. O’HEARN, Facebook, UK and University College London, UK ILYA SERGEY∗, Yale-NUS College, Singapore and University College London, UK Automatic static detection of data races is one of the most basic problems in reasoning about concurrency. We present RacerDÐa static program analysis for detecting data races in Java programs which is fast, can scale to large code, and has proven effective in an industrial software engineering scenario. To our knowledge, RacerD is the first inter-procedural, compositional data race detector which has been empirically shownto have non-trivial precision and impact. Due to its compositionality, it can analyze code changes quickly, and this allows it to perform continuous reasoning about a large, rapidly changing codebase as part of deployment within a continuous integration ecosystem. In contrast to previous static race detectors, its design favors reporting high-confidence bugs over ensuring their absence. RacerD has been in deployment for over a year at Facebook, where it has flagged over 2500 issues that have been fixed by developers before reaching production. It has been important in enabling the development of new code as well as fixing old code: it helped support the conversion of part of the main Facebook Android app from a single-threaded to a multi-threaded architecture. In this paper we describe RacerD’s design, implementation, deployment and impact. CCS Concepts: · Theory of computation → Program analysis; · Software and its engineering → Concurrent programming structures; Additional Key Words and Phrases: Concurrency, Static Analysis, Race Freedom ACM Reference Format: Sam Blackshear, Nikos Gorogiannis, Peter W.
    [Show full text]
  • Monkey: Optimal Navigable Key-Value Store
    Monkey: Optimal Navigable Key-Value Store Niv Dayan Manos Athanassoulis Stratos Idreos Harvard University {dayan, manos, stratos}@seas.harvard.edu ABSTRACT Pareto curve In this paper, we show that key-value stores backed by an LSM-tree exhibit an intrinsic trade-off between lookup cost, update cost, and main memory footprint, yet all existing designs expose a subopti- mal and difficult to tune trade-off among these metrics. We pin- WiredTiger Cassandra, HBase point the problem to the fact that all modern key-value stores sub- RocksDB, LevelDB, cLSM optimally co-tune the merge policy, the buffer size, and the Bloom bLSM Monkey filters’ false positive rates in each level. We present Monkey, an LSM-based key-value store that strikes the optimal balance between the costs of updates and lookups with any given main memory budget. The insight is that worst-case lookup cost is proportional to the sum of the false positive rates Figure 1: State-of-the-art LSM-tree based key-value stores are of the Bloom filters across all levels of the LSM-tree. Contrary not tuned along the Pareto curve. As a result, they are unable to to state-of-the-art key-value stores that assign a fixed number of maximize throughput. In contrast, Monkey is tuned along the bits-per-element to all Bloom filters, Monkey allocates memory Paretro Frontier, and it can navigate it to find the best trade-off to filters across different levels so as to minimize this sum. We for a given application to maximize throughput. show analytically that Monkey reduces the asymptotic complex- enabling (1) high throughput for updates [29] and (2) good space- ity of the worst-case lookup I/O cost, and we verify empirically efficiency as data is stored compactly [14] (as they do not need to using an implementation on top of LevelDB that Monkey reduces keep free space at every node to allow in-place updates).
    [Show full text]
  • Varun Arora 609.790.7855 | [email protected]
    Varun Arora 609.790.7855 | [email protected] EDUCATION EXPERIENCE VANDERBILT UNIVERSITY LIME | SOFTWARE ENGINEER, RIDER GROWTH B.S. IN COMPUTER SCIENCE September 2019 - Present | San Francisco, CA B.S. IN APPLIED MATH • Iterated quickly on short-term user-facing experiments to increase Class of 2019 | Nashville, TN engagement, retention, and monetization. College of Engineering • Worked with a team to launch the LimePass subscription product, creating an in-app notification system that improved conversion by 12%. LEADERSHIP • Provided native mobile support to the Growth team as lead iOS engineer VANDYAPPS PINTEREST | SOFTWARE ENGINEER INTERN | KP FELLOW PRESIDENT June 2019 - August 2019 | San Francisco, CA Organized tech talks, coding • Created a real-time scheduler for shopping ads infrastructure competitions, and hack nights for over • Worked with a team to develop a streaming feed ingestion system, increasing 400 members the speed at which merchant catalogs populate on Pinterest by over 200% VANDYHACKS FACEBOOK | SOFTWARE ENGINEER INTERN DIRECTOR OF DEVELOPMENT January 2018 – April 2018 | London, UK Led a team of eight to build the • Created logging infrastructure in OCaml to allow easy recording of data from software for Tennessee’s largest directly within the open-source Infer static analyzer. hackathon • Implemented performance logging, discovering runtime performance opportunities to improve Infer’s issue reporting speed by 15%. CONTRARY CAPITAL FOUNDING STUDENT PARTNER FACEBOOK | SOFTWARE ENGINEER INTERN Led investment decisions for $5MM May 2017 – August 2017 | Menlo Park, CA portfolio by regularly evaluating • Created data validation tooling for the queueing and storage layers of investment opportunities Messenger infrastructure, enabling removal of extraneous fields. • Built end-to-end pipeline simplifying debugging process for on-call engineers, SKILLS allowing identification of prod issues & reducing issue resolution time by 20%.
    [Show full text]
  • Progress Report of the Max Planck Institute for Software Systems (MPI-SWS)
    Progress Report of the Max Planck Institute for Software Systems (MPI-SWS) August 2015 { January 2018 Contents 1 State of the Institute 7 1.1 General overview of the institute . .7 1.2 The state of the institute, and recent accomplishments . 11 I Current Research Groups 16 2 The Real-Time Systems Group 18 2.1 Overview . 18 2.2 Research agenda . 21 3 The Practical Formal Methods Group 27 3.1 Overview . 27 3.2 Research agenda . 29 4 The Automated Verification and Approximation Group 35 4.1 Overview . 35 4.2 Research agenda . 36 5 The Foundations of Programming Group 42 5.1 Overview . 42 5.2 Research agenda . 44 6 The Distributed Systems Group 51 6.1 Overview . 51 6.2 Research agenda . 54 7 The Large Scale Internet Systems Group 61 7.1 Overview . 61 7.2 Research agenda . 63 8 The Foundations of Computer Security Group 68 8.1 Overview . 68 8.2 Research agenda . 70 9 The Networks and Machine Learning Group 77 9.1 Overview . 77 9.2 Research agenda . 79 10 The Networked Systems Group 85 10.1 Overview . 85 10.2 Research Agenda: Foundations of Social Computing . 89 11 The Rigorous Software Engineering Group 94 11.1 Overview . 94 11.2 Research Agenda . 96 11.3 Formal Methods and Machine Learning . 101 11.4 Program Interactions with the External World . 104 12 The Foundations of Algorithmic Verification Group 109 12.1 Overview . 109 12.2 Research agenda . 110 13 The Machine Teaching Group 115 13.1 Overview . 115 13.2 Research agenda .
    [Show full text]
  • Automatic Program Transformation for Program Repair and Improving Analysis
    Automatic Program Transformation for Program Repair and Improving Analysis Rijnard van Tonder Thesis Committee: Dr. Claire Le Goues (ISR), Dr. Christian Kästner (ISR), Dr. Jan Hoffmann (CSD), Dr. Manuel Fahndrich (Facebook) Wednesday 19th September, 2018 1 Introduction Software bugs are not going away. Millions of dollars and thousands of developer-hours are spent finding bugs, debugging the root cause, writing a patch, and reviewing fixes [16, 60]. Automated tools such as linters, gradual type checkers, and static analyzers help drive down costs by catching bugs early and increase developer efficiency [12, 13, 19]. However, truly fixing bugs remains a predominantly manual and expensive process. Reliance on manual processes further result in fixable bugs (found by automated tools) remaining unfixed. Automatic Program Repair (APR) [44] promises to cut the costs of fixing bugs manually. Automatic program repair is hard: the prospect of automatically changing a program’s semantics can lead to intractable and undesirable behavior [50, 73]. To become mainstream, APR must produce semantically correct patches that can be trusted for automatic application to improve software. The vast majority of APR research rely on existing tests to identify bugs, validate fixes, or both [9, 38, 39, 43, 49, 50, 54, 55, 58, 63, 64, 75, 80]. Tests are appealing because they are readily available in practice, and straightforwardly indicate whether a change improves the program in question (i.e., by turning a previously failing test case into a passing one). However, reliance on tests impose several fundamental limitations to approaches that currently dominate the state of the art in APR. First, tests are inherently limited to executing single paths and may consequently miss bugs.
    [Show full text]
  • Cyberculture and Personnel Security: Report I – Orientation, Concerns, and Needs
    Technical Report 11-01 May 2011 Cyberculture and Personnel Security: Report I – Orientation, Concerns, and Needs John S. Leggitt Olga G. Shechter Northrop Grumman Technical Services Eric L. Lang Defense Personnel Security Research Center Approved for Public Distribution: Distribution Unlimited Defense Personnel Security Research Center Technical Report 11-01 May 2011 Cyberculture and Personnel Security: Report I – Orientation, Concerns, and Needs John S. Leggitt, Olga G. Shechter—Northrop Grumman Technical Services Eric L. Lang—Defense Personnel Security Research Center Released by – James A. Riedel BACKGROUND HIGHLIGHTS Computers and related Information from many sources was technologies, such as smart examined, including academic phones and video games, are now research journals, other federal a common part of everyday life. organizations, news reports, and Many people spend a large portion cyber environments, to understand of their waking hours using and cyber activities relevant to personnel socializing through these devices, security. Participation is widespread forming what is known as a in U.S. society and popular among all cyberculture. Personnel security age groups. Some cyber activities, investigative and adjudicative such as foreign associations, can be standards were developed before reportable per existing investigative these products were widely criteria, so procedures should be available; however, cyberculture updated appropriately and promptly. bears relevance to personnel Other topics require research before security due both to the presence action is recommended. One concern of existing security issues and is how online disinhibition, where potential effects on psychological people who become more willing to outcomes and workplace disclose personal information, performance. Although deceive, or become hostile, affects cyberculture has many beneficial personnel security.
    [Show full text]
  • Automated Fault Localization in Large Java Applications
    Dissertation submitted to the Combined Faculty for the Natural Sciences and for Mathematics of Heidelberg University, Germany for the Degree of Doctor of Natural Sciences Put forward by Mohammadreza Ghanavati (M.Sc.) from Ramhormoz (Iran) Oral examination: Automated Fault Localization in Large Java Applications Advisor: Prof. Dr. Artur Andrzejak Abstract Modern software systems evolve steadily. Software developers change the software codebase every day to add new features, to improve the performance, or to fix bugs. Despite extensive testing and code inspection processes before releasing a new software version, the chance of introducing new bugs is still high. A code that worked yesterday may not work today, or it can show a degraded performance causing software regression. The laws of software evolution state that the complexity increases as software evolves. Such increasing complexity makes software maintenance harder and more costly. In a typical software organization, the cost of debugging, testing, and verification can easily range from 50% to 75% of the total development costs. Given that human resources are the main cost factor in the software maintenance and the software codebase evolves continuously, this dissertation tries to answer the following question: How can we help developers to localize the software defects more effectively during software development? We answer this question in three aspects. First, we propose an approach to localize failure-inducing changes for crashing bugs. Assume the source code of a buggy version, a failing test, the stack trace of the crashing site, and a previous correct version of the application. We leverage program analysis to contrast the behavior of the two software versions under the failing test.
    [Show full text]