DOCSLIB.ORG

Automatic Algorithmic Complexity Determination Using Dynamic Program Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Automatic Algorithmic Complexity Determination Using Dynamic Program Analysis Automatic Algorithmic Complexity Determination Using Dynamic Program Analysis Istvan Gergely Czibula, Zsuzsanna Onet¸-Marian and Robert-Francisc Vida Department of Computer Science, Babes¸-Bolyai University, M. Kogalniceanu Street, Cluj-Napoca, Romania Keywords: Algorithmic Complexity, Dynamic Program Analysis. Abstract: Algorithm complexity is an important concept in computer science concerned with the efficiency of algo- rithms. Understanding and improving the performance of a software system is a major concern through the lifetime of the system especially in the maintenance and evolution phase of any software. Identifying certain performance related issues before they actually affect the deployed system is desirable and possible if devel- opers know the algorithmic complexity of the methods from the software system. In many software projects, information related to algorithmic complexity is missing, thus it is hard for a developer to reason about the performance of the system for different input data sizes. The goal of this paper is to propose a novel method for automatically determining algorithmic complexity based on runtime measurements. We evaluate the pro- posed approach on synthetic data and actual runtime measurements of several algorithms in order to assess its potential and weaknesses. 1 INTRODUCTION son about the performance characteristics of a given algorithm for increasing size of the input data. In The performance of a software application is one of essence, studying efficiency means to predict the re- the most important aspect for any real life software. sources needed for executing a given algorithm for After the functional requirements are satisfied, soft- various inputs. ware developers try to predict and improve the per- formance of the software in order to meet user expec- 1.1 Motivation tations. Performance related activities include modi- fication of the software in order to reduce the amount While in case of library functions, especially stan- of internal storage used by the application, increase dard library functions, complexity guarantees for the the execution speed by replacing algorithms or com- exposed methods exist, such information is generally ponents and improve the system reliability and robust- omitted from the developer code and documentation. ness (Chapin et al., 2001). The main reason for this is the difficulty of deduc- Simulation, profiling and measurements are per- ing said information by the software developer. Ana- formed in order to assess the performance of the sys- lyzing even a simple algorithm may require a good tem during maintenance (McCall et al., 1985), but us- understanding of combinatorics, probability theory ing just measurements performed on a developer ma- and algebraic dexterity (Cormen et al., 2001). Au- chine can be misleading and may not provide suffi- tomated tools, created based on the theoretical model cient insight into the performance of the deployed sys- presented in this paper can overcome this difficulty. tem on possible different real life data load. Profiling Knowledge about algorithmic complexity can is a valuable tool but, as argued in (W. Kernighan and complement existing software engineering practices J. Van Wyk, 1998), no benchmark result should ever for evaluating and improving the efficiency of a soft- be taken at face value. ware system. The main advantage of knowing the Analysis of an algorithm, introduced by (Knuth, complexity of a method is that it gives an insight into 1998) is concerned with the study of the efficiency of the performance of an operation for large input data algorithms. Using algorithm analysis one can com- sizes. Profiling and other measurement based tech- pare several algorithms for the same problem, based niques can not predict the performance characteristics on the efficiency profile of each algorithm or can rea- of a method for other than the data load under which 186 Czibula, I., One¸t-Marian, Z. and Vida, R. Automatic Algorithmic Complexity Determination Using Dynamic Program Analysis. DOI: 10.5220/0007831801860193 In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 186-193 ISBN: 978-989-758-379-7 Copyright c 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Automatic Algorithmic Complexity Determination Using Dynamic Program Analysis the measurements were performed. While they do not focus on determining the com- Knowledge about algorithmic complexity is also plexity of the source code directly, there are several beneficial for mitigating security issues in software approaches that try to find performance bugs (pieces systems. There is a well documented class of low- of code that function correctly, but where functional- bandwidth denial of service (DoS) attacks in the lit- ity preserving changes can lead to substantial perfor- erature that exploit algorithmic deficiencies in soft- mance improvement) in the source code, for example: ware systems (Crosby and Wallach, 2003). The first (Luo et al., 2017), (Olivo et al., 2015) and (Chen et al., line of defence against such attacks would be to prop- 2018). erly identify algorithmic complexity for the opera- An approach using evolutionary search techniques tions within the software system. for generating input data that trigger worst case com- The main contributions of this paper is to pro- plexity is presented in (Crosby and Wallach, 2003). pose and experimentally evaluate a deterministic ap- Such approaches are complementary to our approach proach to find the asymptotic algorithmic complexity which assumes that testing data already exists. for a method. To the best of our knowledge there is no other approach in the literature that automatically determines algorithmic method complexity based on 3 METHODOLOGY runtime data analysis. The most used representation for algorithm ana-lysis is the one proposed in (Knuth, 1998), the asymptotic representation, based on the Big O notation, a conve- 2 RELATED WORK nient way to deal with approximations introduced by Paul Bachmann in (Bachmann, 1894). In this section we will present a short overview of Definition 1. O( f (n)) denotes the set of g(n) such some existing approaches from the literature related that there exist positive constants C and nO with to algorithmic complexity. jg(n)j ≤ C ∗ f (n) for all n ≥ n0. The first approaches, for example (Le Metayer,´ If we denote by T(n) the number of steps per- 1988), (Wegbreit, 1975) and (Rosendahl, 1989), were formed by a given algorithm (n is the size of the input based on source code analysis and the computation of data), then the problem of identifying the algorithmic mathematical expressions describing the exact num- complexity becomes finding a function f (n) such that ber of steps performed by the algorithm. While such T(n) 2 O( f (n)). The basic idea is to find a function methods can compute the exact complexity bound of f (n) that provides an asymptotic upper bound for the an algorithm, they were defined for functional pro- number of steps that is performed by the algorithm. gramming languages and recursive functions. When analyzing algorithmic complexity, we are More recent approaches can be applied for other not differentiating between functions like f (n) = programming languages as well, but many of them 2n2 + 7 and f (n) = 8n2 + 2n + 1 the complexity in focus only on determining the complexity of spe- both cases will be T(n) 2 O(n2). The result of algo- cific parts of the source code (usually loops). Such rithm analysis is an approximation indicating the or- approach is the hybrid (composed of static and der of growth of the running time with respect to the dynamic analysis) method presented in (Demontieˆ input data size (Cormen et al., 2001). While the com- et al., 2015) and the modular approach presented in plexity function can be any function, there is a set of (Brockschmidt et al., 2014). well known and widely used functions in the literature Goldsmith et al. introduced in (Goldsmith et al., used to communicate complexity guarantees. In this 2007) a model that explains the performance of a pro- paper we use the functions from Table 1, but the set gram as a feature of the input data. The focus is on can be extended without loosing the applicability of presenting the performance profile (empirical compu- the proposed method. The considered functions rep- tational complexity) of the entire program and not the resent complexity classes that appear frequently for identification of algorithmic complexity at the method real life software systems (Weiss, 2012). level. In conclusion, the problem of identifying algorith- Benchmark is a library, written in C++, that sup- mic complexity becomes selecting the most appropri- ports benchmarking C++ code (Benchmark, 2016). ate function f (n) from a predefined set, such that f (n) Though it is not its main functionality, it also sup- best describes the order of growth of the running time ports the empirical computation of asymptotic com- of the analyzed method for increasing input data sizes. plexities. A comparison of our approach to the results In this paper we introduce an automated approach provided by Benchmark are presented in Section 5. for identifying algorithmic complexity for a method 187 ICSOFT 2019 - 14th International Conference on Software Technologies in a software system based on runtime measurements. In the definition of the Big O notation, the only re- The basic idea is to measure the execution time of quirement regarding the constant C is that it should be the analyzed method for different input sizes and use positive, but no upper limit is set, since the inequal- these measurements to identify the best fitting com- ity from the definition should be true for all values plexity function. The proposed approach consists of of n ≥ n0 . However, in our approach the value n three steps described in the following sections. (i.e., the size of the input data) is finite, it has a max- imum value, which means that the values of the con- 3.1 Step 1 - Data Collection stants c1;c2 should also be restricted.
Load more

Recommended publications
  • Advanced Systems Security: Symbolic Execution
    Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Advanced Systems Security:! Symbolic Execution Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University Systems and Internet Infrastructure Security (SIIS) Laboratory Page 1 Problem • Programs have flaws ‣ Can we find (and fix) them before adversaries can reach and exploit them? • Then, they become “vulnerabilities” Systems and Internet Infrastructure Security (SIIS) Laboratory Page 2 Vulnerabilities • A program vulnerability consists of three elements: ‣ A flaw ‣ Accessible to an adversary ‣ Adversary has the capability to exploit the flaw • Which one should we focus on to find and fix vulnerabilities? ‣ Different methods are used for each Systems and Internet Infrastructure Security (SIIS) Laboratory Page 3 Is It a Flaw? • Problem: Are these flaws? ‣ Failing to check the bounds on a buffer write? ‣ printf(char *n); ‣ strcpy(char *ptr, char *user_data); ‣ gets(char *ptr) • From man page: “Never use gets().” ‣ sprintf(char *s, const char *template, ...) • From gnu.org: “Warning: The sprintf function can be dangerous because it can potentially output more characters than can fit in the allocation size of the string s.” • Should you fix all of these? Systems and Internet Infrastructure Security (SIIS) Laboratory Page 4 Is It a Flaw? • Problem: Are these flaws? ‣ open( filename, O_CREAT );
    [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]
  • The Art, Science, and Engineering of Fuzzing: a Survey
    1 The Art, Science, and Engineering of Fuzzing: A Survey Valentin J.M. Manes,` HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo Abstract—Among the many software vulnerability discovery techniques available today, fuzzing has remained highly popular due to its conceptual simplicity, its low barrier to deployment, and its vast amount of empirical evidence in discovering real-world software vulnerabilities. At a high level, fuzzing refers to a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed. While researchers and practitioners alike have invested a large and diverse effort towards improving fuzzing in recent years, this surge of work has also made it difficult to gain a comprehensive and coherent view of fuzzing. To help preserve and bring coherence to the vast literature of fuzzing, this paper presents a unified, general-purpose model of fuzzing together with a taxonomy of the current fuzzing literature. We methodically explore the design decisions at every stage of our model fuzzer by surveying the related literature and innovations in the art, science, and engineering that make modern-day fuzzers effective. Index Terms—software security, automated software testing, fuzzing. ✦ 1 INTRODUCTION Figure 1 on p. 5) and an increasing number of fuzzing Ever since its introduction in the early 1990s [152], fuzzing studies appear at major security conferences (e.g. [225], has remained one of the most widely-deployed techniques [52], [37], [176], [83], [239]). In addition, the blogosphere is to discover software security vulnerabilities. At a high level, filled with many success stories of fuzzing, some of which fuzzing refers to a process of repeatedly running a program also contain what we consider to be gems that warrant a with generated inputs that may be syntactically or seman- permanent place in the literature.
    [Show full text]
  • Static Program Analysis As a Fuzzing Aid
    Static Program Analysis as a Fuzzing Aid Bhargava Shastry1( ), Markus Leutner1, Tobias Fiebig1, Kashyap Thimmaraju1, Fabian Yamaguchi2, Konrad Rieck2, Stefan Schmid3, Jean-Pierre Seifert1, and Anja Feldmann1 1 TU Berlin, Berlin, Germany [email protected] 2 TU Braunschweig, Braunschweig, Germany 3 Aalborg University, Aalborg, Denmark Abstract. Fuzz testing is an effective and scalable technique to per- form software security assessments. Yet, contemporary fuzzers fall short of thoroughly testing applications with a high degree of control-flow di- versity, such as firewalls and network packet analyzers. In this paper, we demonstrate how static program analysis can guide fuzzing by aug- menting existing program models maintained by the fuzzer. Based on the insight that code patterns reflect the data format of inputs pro- cessed by a program, we automatically construct an input dictionary by statically analyzing program control and data flow. Our analysis is performed before fuzzing commences, and the input dictionary is sup- plied to an off-the-shelf fuzzer to influence input generation. Evaluations show that our technique not only increases test coverage by 10{15% over baseline fuzzers such as afl but also reduces the time required to expose vulnerabilities by up to an order of magnitude. As a case study, we have evaluated our approach on two classes of network applications: nDPI, a deep packet inspection library, and tcpdump, a network packet analyzer. Using our approach, we have uncovered 15 zero-day vulnerabilities in the evaluated software that were not found by stand-alone fuzzers. Our work not only provides a practical method to conduct security evalua- tions more effectively but also demonstrates that the synergy between program analysis and testing can be exploited for a better outcome.
    [Show full text]
  • A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks
    A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks Pallavi Joshi Chang-Seo Park Mayur Naik Koushik Sen Intel Research, Berkeley, USA EECS Department, UC Berkeley, USA [email protected] {pallavi,parkcs,ksen}@cs.berkeley.edu Abstract cipline followed by the parent software and this sometimes results We present a novel dynamic analysis technique that finds real dead- in deadlock bugs [17]. locks in multi-threaded programs. Our technique runs in two stages. Deadlocks are often difficult to find during the testing phase In the first stage, we use an imprecise dynamic analysis technique because they happen under very specific thread schedules. Coming to find potential deadlocks in a multi-threaded program by observ- up with these subtle thread schedules through stress testing or ing an execution of the program. In the second stage, we control random testing is often difficult. Model checking [15, 11, 7, 14, 6] a random thread scheduler to create the potential deadlocks with removes these limitations of testing by systematically exploring high probability. Unlike other dynamic analysis techniques, our ap- all thread schedules. However, model checking fails to scale for proach has the advantage that it does not give any false warnings. large multi-threaded programs due to the exponential increase in We have implemented the technique in a prototype tool for Java, the number of thread schedules with execution length. and have experimented on a number of large multi-threaded Java Several program analysis techniques, both static [19, 10, 2, 9, programs. We report a number of previously known and unknown 27, 29, 21] and dynamic [12, 13, 4, 1], have been developed to de- real deadlocks that were found in these benchmarks.
    [Show full text]
  • Seminar on Program Analysis ECS 289C (Programming Languages and Compilers) Winter 2015 Preliminary Reading List
    Seminar on Program Analysis ECS 289C (Programming Languages and Compilers) Winter 2015 Preliminary Reading List 1. Abstract Interpretation and Dataflow Analysis (a) Global Data Flow Analysis and Iterative Algorithms [J.ACM'76] (b) Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints [POPL'77] (c) Precise Interprocedural Dataflow Analysis via Graph Reachability [POPL'95] 2. Pointer Analysis (a) Points-to Analysis in Almost Linear Time [POPL'96] (b) Pointer Analysis: Haven't We Solved This Problem Yet? [PASTE'01] (c) The Ant and the Grasshoper: Fast and Accurate Pointer Analysis for Millions of Lines of Code [PLDI'07] 3. Program Slicing (a) Interprocedural Slicing Using Dependence Graphs [PLDI'88] (b) Dynamic Program Slicing [PLDI'90] 4. Dynamic Symbolic Execution and Test Generation (a) DART: Directed Automated Random Testing [PLDI'05] (b) CUTE: A Concolic Unit Testing Engine for C [FSE'05] (c) KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex System Programs [OSDI'08] 5. Model Checking (a) Counterexample-Guided Abstraction Refinement [CAV'00] (b) Automatic predicate abstraction of C programs [PLDI'01] (c) Lazy Abstraction [POPL'02] 6. Concurrency (a) Learning from Mistakes: A Comprehensive Study on Real World Concurrency Bug Characteristics [ASPLOS'08] (b) Finding and Reproducing Heisenbugs in Concurrent Programs [OSDI'08] 1 (c) Life, Death, and the Critical Transition: Finding Liveness Bugs in Systems Code [NSDI'07] (d) RacerX: Effective, Static Detection of Race Conditions and Deadlocks [SOSP'03] (e) FastTrack: Efficient and Precise Dynamic Race Detection [PLDI'09] (f) A Randomized Dynamic Program Analysis Technique for Detecting Real Dead- locks [PLDI09] 7.
    [Show full text]
  • Decoupling Dynamic Program Analysis from Execution in Virtual Environments
    Decoupling dynamic program analysis from execution in virtual environments Jim Chow Tal Garfinkel Peter M. Chen VMware Abstract 40x [18, 26], rendering many production workloads un- Analyzing the behavior of running programs has a wide usable. In non-production settings, such as program de- variety of compelling applications, from intrusion detec- velopment or quality assurance, this overhead may dis- tion and prevention to bug discovery. Unfortunately, the suade use in longer, more realistic tests. Further, the per- high runtime overheads imposed by complex analysis formance perturbations introduced by these analyses can techniques makes their deployment impractical in most lead to Heisenberg effects, where the phenomena under settings. We present a virtual machine based architec- observation is changed or lost due to the measurement ture called Aftersight ameliorates this, providing a flex- itself [25]. ible and practical way to run heavyweight analyses on We describe a system called Aftersight that overcomes production workloads. these limitations via an approach called decoupled analy- Aftersight decouples analysis from normal execution sis. Decoupled analysis moves analysis off the computer by logging nondeterministic VM inputs and replaying that is executing the main workload by separating execu- them on a separate analysis platform. VM output can tion and analysis into two tasks: recording, where system be gated on the results of an analysis for intrusion pre- execution is recorded in full with minimal interference, vention or analysis can run at its own pace for intrusion and analysis, where the log of the execution is replayed detection and best effort prevention. Logs can also be and analyzed. stored for later analysis offline for bug finding or foren- Aftersight is able to record program execution effi- sics, allowing analyses that would otherwise be unusable ciently using virtual machine recording and replay [4, 9, to be applied ubiquitously.
    [Show full text]
  • Practical Concurrency Testing Or: How I Learned to Stop Worrying and Love the Exponential Explosion
    Practical Concurrency Testing or: How I Learned to Stop Worrying and Love the Exponential Explosion Ben Blum Decembruary 2018 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Garth Gibson, Chair David A. Eckhardt Brandon Lucia Haryadi Gunawi, University of Chicago Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright © 2018 Ben Blum September 20, 2018 DRAFT Keywords: landslide terminal, baggage claim, ground transportation, ticketing September 20, 2018 DRAFT For my family, my teachers, and my students. September 20, 2018 DRAFT iv September 20, 2018 DRAFT Abstract Concurrent programming presents a challenge to students and experts alike because of the complexity of multithreaded interactions and the diffi- culty to reproduce and reason about bugs. Stateless model checking is a con- currency testing approach which forces a program to interleave its threads in many different ways, checking for bugs each time. This technique is power- ful, in principle capable of finding any nondeterministic bug in finite time, but suffers from exponential explosion as program size increases. Checking an exponential number of thread interleavings is not a practical or predictable approach for programmers to find concurrency bugs before their project dead- lines. In this thesis, I develop several new techniques to make stateless model checking more practical for human use. I have built Landslide, a stateless model checker specializing in undergraduate operating systems class projects. Landslide extends the traditional model checking algorithm with a new frame- work for automatically managing multiple state spaces according to their esti- mated completion times, which I show quickly finds bugs should they exist and also quickly verifies correctness otherwise.
    [Show full text]
  • Detecting PHP-Based Cross-Site Scripting Vulnerabilities Using Static Program Analysis
    Detecting PHP-based Cross-Site Scripting Vulnerabilities Using Static Program Analysis A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Cyber Security by Steven M. Kelbley B.S. Biological Sciences, Wright State University, 2012 2016 Wright State University i WRIGHT STATE UNIVERSITY GRADUATE SCHOOL December 1, 2016 I HEREBY RECOMMEND THAT THE THESIS PREPARED UNDER MY SUPERVISION BY Steven M. Kelbley ENTITLED Detecting PHP-based Cross-Site Scripting Vulnerabilities Using Static Program Analysis BE ACCEPTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Science in Cyber Security. _________________________________ Junjie Zhang, Ph.D. Thesis Director _________________________________ Mateen Rizki, Ph.D. Chair, Department of Computer Science and Engineering Committee on Final Examination _________________________________ Junjie Zhang, Ph.D. _________________________________ Krishnaprasad Thirunarayan, Ph.D. _________________________________ Adam Bryant, Ph.D. _________________________________ Robert E. W. Fyffe, Ph.D. Vice President for Research and Dean of the Graduate School ABSTRACT Kelbley, Steven. M.S. Cyber Security, Department of Computer Science, Wright State University, 2016. Detecting PHP-based Cross-Site Scripting Vulnerabilities Using Static Program Analysis. With the widespread adoption of dynamic web applications in recent years, a number of threats to the security of these applications have emerged as significant challenges for application developers. The security of developed applications has become a higher pri- ority for both developers and their employers as cyber attacks become increasingly more prevalent and damaging. Some of the most used web application frameworks are written in PHP and have be- come major targets due to the large number of servers running these applications world- wide.
    [Show full text]
  • Introduction to Dynamic Program Analysis with Disl
    Introduction to Dynamic Program Analysis with DiSL Lukáš Marek Yudi Zheng Danilo Ansaloni Charles University University of Lugano University of Lugano Prague, Czech Republic Lugano, Switzerland Lugano, Switzerland [email protected] fi[email protected] fi[email protected] Lubomír Bulej Aibek Sarimbekov Walter Binder Charles University University of Lugano University of Lugano Prague, Czech Republic Lugano, Switzerland Lugano, Switzerland [email protected] fi[email protected] fi[email protected] Zhengwei Qi Shanghai Jiao Tong University Shanghai, China [email protected] ABSTRACT give the expert developer many opprtunities to optimize the DiSL is a new domain-specific language for bytecode instru- inserted code, enabling efficient DPA tools. mentation with complete bytecode coverage. It reconciles Some researchers have proposed the use of aspect-oriented expressiveness and efficiency of low-level bytecode manipu- programming (AOP) for creating DPA tools. Thanks to lation libraries with a convenient, high-level programming its pointcut/advice mechanism, AOP offers a high abstrac- model inspired by aspect-oriented programming. This paper tion level that allows to concisely specify certain kinds of summarizes the language features of DiSL and gives a brief instrumentations. Consequently, the use of AOP promises overview of several dynamic program analysis tools that were to significantly reduce the development effort for building ported to DiSL. DiSL is available as open-source under the DPA tools. Unfortunately, mainstream AOP languages such Apache 2.0 license. as AspectJ lack join points at the level of e.g. basic blocks of code or individual bytecodes that would be needed for cer- tain DPA tools.
    [Show full text]
  • Combining Static and Dynamic Program Analysis Techniques for Checking Relational Properties
    Combining Static and Dynamic Program Analysis Techniques for Checking Relational Properties zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften von der KIT-Fakultät für Informatik des Karlsruher Instituts für Technologie (KIT) genehmigte Dissertation von Mihai Herda aus Bras, ov, Rumänien Tag der mündlichen Prüfung: 13.12.2019 Erster Gutachter: Prof. Dr. Bernhard Beckert Zweiter Gutachter: Prof. Dr. Shmuel Tyszberowicz Combining Static and Dynamic Program Analysis Techniques for Checking Relational Properties Mihai Herda Ich versichere wahrheitsgemäß, die Dissertation bis auf die dort angegebe- nen Hilfen selbständig angefertigt, alle benutzten Hilfsmittel vollständig und genau angegeben und alles kenntlich gemacht zu haben, was aus Arbeiten anderer und eigenen Veröffentlichungen unverändert oder mit Änderungen entnommen wurde. Karlsruhe, Mihai Herda Acknowledgements I thank Prof. Bernhard Beckert for giving me the opportunity to pursue a PhD in his research group and for his useful advice throughout my time as a PhD student. I thank Prof. Shmuel Tyszberowicz for the great collaboration that we had, for his feedback, and for agreeing to be the second reviewer of this thesis. I thank my current and former colleagues, Aboubakr Achraf El Ghazi, Thorsten Bormer, Stephan Falke, David Farago, Christoph Gladisch, Da- niel Grahl, Sarah Grebing, Markus Iser, Michael Kirsten, Jonas Klamroth, Vladimir Klebanov, Marko Kleine Büning, Tianhai Liu, Simone Meinhart, Florian Merz, Jonas Schiffl, Christoph Scheben, Prof. Peter Schmitt, Prof. Carsten Sinz, Mattias Ulbrich, and Alexander Weigl, for the great collabora- tion and for the great discussions that we had during this time. Working with you is and has been a pleasure. I thank the students Etienne Brunner, Stephan Gocht, Holger Klein, Daniel Lentzsch, Joachim Müssig, Joana Plewnia, Ulla Scheler, Chiara Staudenmaier, Benedikt Wagner, and Pascal Zwick, for their work that I had the pleasure to supervise.
    [Show full text]
  • Dynamic Tracing with Dtrace & Systemtap
    Dynamic Tracing with DTrace SystemTap Sergey Klyaus Copyright © 2011-2016 Sergey Klyaus This work is licensed under the Creative Commons Attribution-Noncommercial-ShareAlike 3.0 License. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Table of contents Introduction 7 Foreword . 7 Typographic conventions . 9 TSLoad workload generator . 12 Operating system Kernel . 14 Module 1: Dynamic tracing tools. dtrace and stap tools 15 Tracing . 15 Dynamic tracing . 16 DTrace . 17 SystemTap . 19 Safety and errors . 22 Stability . 23 Module 2: Dynamic tracing languages 25 Introduction . 25 Probes . 27 Arguments . 33 Context . 34 Predicates . 35 Types and Variables . 37 Pointers . 40 Strings and Structures . 43 Exercise 1 . 44 Associative arrays and aggregations . 44 Time . 48 Printing and speculations . 48 Tapsets translators . 50 Exercise 2 . 52 Module 3: Principles of dynamic tracing 54 Applying tracing . 54 Dynamic code analysis . 55 Profiling . 61 Performance analysis . 65 Pre- and post-processing . 66 Vizualization . 70 Module 4: Operating system kernel tracing 74 Process management . 74 3 Exercise 3 . 86 Process scheduler . 87 Virtual Memory . 105 Exercise 4 . 116 Virtual File System . 116 Block Input-Output . 122 Asynchronicity in kernel . 131 Exercise 5 . 132 Network Stack . 134 Synchronization primitives . 138 Interrupt handling and deferred execution . 143 Module 5: Application tracing 146 Userspace process tracing . 146 Unix C library . 149 Exercise 6 . 152 Java Virtual Machine . 153 Non-native languages . 160 Web applications . 165 Exercise 7 . 172 Appendix A. Exercise hints and solutions 173 Exercise 1 .
    [Show full text]