DOCSLIB.ORG

Towards Efficient Instrumentation for Reverse-Engineering Object Oriented Software Through Static and Dynamic Analyses

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Towards Efficient Instrumentation for Reverse-Engineering Object Oriented Software Through Static and Dynamic Analyses Towards Efficient Instrumentation for Reverse-Engineering Object Oriented Software through Static and Dynamic Analyses by Hossein Mehrfard A dissertation submitted to the Faculty of Graduate and Postdoctoral Affairs in partial fulfillment of the requirements for the degree of Doctor of Philosophy in The Ottawa-Carleton Institute for Electrical and Computer Engineering Carleton University Ottawa, Ontario © 2017 Hossein Mehrfard Abstract In software engineering, program analysis is usually classified according to static analysis (by analyzing source code) and dynamic analysis (by observing program executions). While static analysis provides inaccurate and imprecise results due to programming language's features (e.g., late binding), dynamic analysis produces more accurate and precise results at runtime at the expense of longer executions to collect traces. One prime mechanism to observe executions in dynamic analysis is to instrument either the code or the binary/byte code. Instrumentation overhead potentially poses a serious threat to the accuracy of the dynamic analysis, especially for time dependent software systems (e.g., real-time software), since it can cause those software systems to go out of synchronization. For instance, in a typical real-time software, the dynamic analysis result is correct if the instrumentation overhead, which is due to gathering dynamic information, does not add to the response time of real-time behaviour to the extent that deadlines may be missed. If a deadline is missed, the dynamic analysis result and the system’s output are not accurate. There are two ways to increase accuracy of a dynamic analysis: devising more efficient instrumentation and using a hybrid (static plus dynamic) analysis. A hybrid analysis is a favourable approach to cope with the overhead problem over a purely dynamic analysis. Yet, in the context of reverse engineering source code to produce method calls dynamic and hybrid instrumentations typically lead to large execution traces and consequently large execution overhead. ii This thesis is a step towards efficient and accurate information collection through a hybrid analysis procedure to reverse engineer source code to produce method calls, with the prime objective to reduce instrumentation overhead. To that aim, the first contribution of this thesis is to systematically analyze the contribution to instrumentation overhead of different elements of an existing and promising hybrid solution. Then, a second contribution of the thesis is to suggest an instrumentation optimization process with a range of different designs for those elements to reduce the overhead and select the best one for each element to optimize that solution. The resulting optimized hybrid technique, our third contribution, which potentially produces more accurate instrumentation compared to that hybrid solution for multi-thread software by reducing execution overhead by three quarters, has a reasonable efficiency to reverse engineer programs to produce method calls for multi-threaded software. A final contribution of this thesis is to suggest a set of recommendations for efficient instrumentation. iii Acknowledgements First and foremost, thanks to the God, for shedding lights throughout my life. The God who resembles to nothing and falls beyond any imagination. I would like to express my sincere gratitude to my Ph.D. advisor, Prof. Yvan Labiche for the continuous technical and financial support during the course of my Ph.D. Your professionalism and decency have always been exemplary for me. I learned a great deal from you during my Ph.D. study, especially your attention to details finally taught me to how to craft a perfect software engineering experiment. Thank you Yvan for making my Ph.D. an exciting experience. I would like to thank my Ph.D. committee members, Prof. Guéhéneuc, Prof. Lethbridge, Prof. Franks, and Prof. Baysal for taking their time and reading my thesis. Your insightful comments and different perspectives improved the quality of this manuscript. My special thanks to my fiancé, Sara. Your love and emotional support motivated me to finish this work. Thank you Sara. My deep gratitude to my parents, Masoud and Mojgan, for their unconditional love and constant support, I owe it all to you. I am grateful to my brothers, Ali and Ehsan, who have supported me along the way. I would like to appreciate the SCE staffs, especially Jerry Buburuz and Daren Russ for facilitating my experiments and helping me with the last minute favours. My appreciation also goes to my friends at Carleton university Ehsan Rahimi and Alireza Sharifian for making my Ph.D. an enjoyable experience. Also, I am grateful to my friend Alireza Salimi for the stimulating discussions and his help on my Ph.D. iv Last but not the least, I would like to thank my fellow labmates in SQUALL laboratory for the constructive discussions and their feedback, and for the sleepless nights we were working together before deadlines. v Table of Contents Abstract .............................................................................................................................. ii Acknowledgements .......................................................................................................... iv Table of Contents ............................................................................................................. vi List of Tables .................................................................................................................... ix List of Figures ................................................................................................................... xi 1 Introduction .............................................................................................................................. 1 1.1 Contributions .............................................................................................................. 8 1.2 Manuscript Organization ............................................................................................ 9 2 Background and related work ................................................................................................. 11 2.1 Background .............................................................................................................. 11 2.2 Related works ........................................................................................................... 26 3 An Existing Hybrid Reverse Engineering Approach .............................................................. 52 3.1 Control flow and trace information .......................................................................... 53 3.2 Tool support ............................................................................................................. 56 3.3 Conclusion ............................................................................................................... 72 4 Investigating the Overhead of Kolbah’s Hybrid Approach .................................................... 74 4.1 Research Questions .................................................................................................. 75 4.2 Case studies .............................................................................................................. 77 4.3 Experiment set up ..................................................................................................... 80 4.4 Measurement framework ......................................................................................... 83 4.5 Criteria to select case study ...................................................................................... 86 4.6 Experimental design for overhead study .................................................................. 88 4.7 Results of overhead study ........................................................................................ 90 4.8 Probe effect on functional behaviour ....................................................................... 97 vi 4.9 Identifying potential improvement areas in Light .................................................... 99 4.10 Conclusion ............................................................................................................. 113 5 Optimizing the Hybrid Approach ......................................................................................... 114 5.1 Characteristics of the dynamic analysis ................................................................. 115 5.2 Research Questions ................................................................................................ 117 5.3 Case studies and experiment set up ........................................................................ 118 5.4 Optimizing the Light Instrumentation .................................................................... 119 5.5 Optimized dynamic analysis .................................................................................. 156 5.6 Frequency of probe effect observation ................................................................... 160 5.7 Threats to Validity .................................................................................................. 163 5.8 Conclusion ............................................................................................................. 163 6 Conclusion ............................................................................................................................ 165 6.1 Contribution ..........................................................................................................
Load more

Recommended publications
  • Lttng and the Love of Development Without Printf() [email protected]
    Fosdem 2014 + LTTng and the love of development without printf() [email protected] 1 whoami David Goulet, Software Developer, EfficiOS, Maintainer of LTTng-tools project ● https://git.lttng.org//lttng-tools.git 2 Content Quick overview of LTTng 2.x Everything else you need to know! Recent features & future work. 3 What is tracing? ● Recording runtime information without stopping the process – Enable/Disable event(s) at runtime ● Usually used during development to solve problems like performance, races, etc... ● Lots of possibilities on Linux: LTTng, Perf, ftrace, SystemTap, strace, ... 4 OverviewOverview ofof LTTngLTTng 2.x2.x 5 Overview of LTTng 2.x Unified user interface, kernel and user space tracers combined. (No need to recompile kernel) Trace output in a unified format (CTF) – https://git.efficios.com/ctf.git Low overhead, Shipped in distros: Ubuntu, Debian, Suse, Fedora, Linaro, Wind River, etc. 6 Tracers ● lttng-modules: kernel tracer module, compatible with kernels from 2.6.38* to 3.13.x, ● lttng-ust: user-space tracer, in-process library. * Kernel tracing is now possible on 2.6.32 to 2.6.37 by backport of 3 Linux Kernel patches. 7 Utilities ● lttng-tools: cli utilities and daemons for trace control, – lttng: cli utility for tracing control, – lttng-ctl: tracing control API, – lttng-sessiond: tracing registry daemon, – lttng-consumerd: extract trace data, – lttng-relayd: network streaming daemon. 8 Viewers ● babeltrace: cli text viewer, trace converter, plugin system, ● lttngtop: ncurse top-like viewer, ● Eclipse lttng plugin: front-end for lttng, collect, visualize and analyze traces, highly extensible. 9 LTTng-UST – How does it work? Users instrument their applications with static tracepoints, liblttng-ust, in-process library, dynamically linked with application, Session setup, etc., Run app, collect traces, Post analysis with viewers.
    [Show full text]
  • Flame Graphs Freebsd
    FreeBSD Developer and Vendor Summit, Nov, 2014 Flame Graphs on FreeBSD Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg Agenda 1. Genesis 2. Generaon 3. CPU 4. Memory 5. Disk I/O 6. Off-CPU 7. Chain 1. Genesis The Problem • The same MySQL load on one host runs at 30% higher CPU than another. Why? • CPU profiling should answer this easily # dtrace -x ustackframes=100 -n 'profile-997 /execname == "mysqld"/ {! @[ustack()] = count(); } tick-60s { exit(0); }'! dtrace: description 'profile-997 ' matched 2 probes! CPU ID FUNCTION:NAME! 1 75195 :tick-60s! [...]! libc.so.1`__priocntlset+0xa! libc.so.1`getparam+0x83! libc.so.1`pthread_getschedparam+0x3c! libc.so.1`pthread_setschedprio+0x1f! mysqld`_Z16dispatch_command19enum_server_commandP3THDPcj+0x9ab! mysqld`_Z10do_commandP3THD+0x198! mysqld`handle_one_connection+0x1a6! libc.so.1`_thrp_setup+0x8d! libc.so.1`_lwp_start! 4884! ! mysqld`_Z13add_to_statusP17system_status_varS0_+0x47! mysqld`_Z22calc_sum_of_all_statusP17system_status_var+0x67! mysqld`_Z16dispatch_command19enum_server_commandP3THDPcj+0x1222! mysqld`_Z10do_commandP3THD+0x198! mysqld`handle_one_connection+0x1a6! libc.so.1`_thrp_setup+0x8d! libc.so.1`_lwp_start! 5530! # dtrace -x ustackframes=100 -n 'profile-997 /execname == "mysqld"/ {! @[ustack()] = count(); } tick-60s { exit(0); }'! dtrace: description 'profile-997 ' matched 2 probes! CPU ID FUNCTION:NAME! 1 75195 :tick-60s! [...]! libc.so.1`__priocntlset+0xa! libc.so.1`getparam+0x83! this stack libc.so.1`pthread_getschedparam+0x3c!
    [Show full text]
  • Linuxcon North America 2012
    LinuxCon North America 2012 LTTng 2.0 : Tracing, Analysis and Views for Performance and Debugging. E-mail: [email protected] Mathieu Desnoyers August 29th, 2012 1 > Presenter ● Mathieu Desnoyers ● EfficiOS Inc. ● http://www.efficios.com ● Author/Maintainer of ● LTTng, LTTng-UST, Babeltrace, Userspace RCU Mathieu Desnoyers August 29th, 2012 2 > Content ● Tracing benefits, ● LTTng 2.0 Linux kernel and user-space tracers, ● LTTng 2.0 usage scenarios & viewers, ● New features ready for LTTng 2.1, ● Conclusion Mathieu Desnoyers August 29th, 2012 3 > Benefits of low-impact tracing in a multi-core world ● Understanding interaction between ● Kernel ● Libraries ● Applications ● Virtual Machines ● Debugging ● Performance tuning ● Monitoring Mathieu Desnoyers August 29th, 2012 4 > Tracing use-cases ● Telecom ● Operator, engineer tracing systems concurrently with different instrumentation sets. ● In development and production phases. ● High-availability, high-throughput servers ● Development and production: ensure high performance, low-latency in production. ● Embedded ● System development and production stages. Mathieu Desnoyers August 29th, 2012 5 > LTTng 2.0 ● Rich ecosystem of projects, ● Key characteristics of LTTng 2.0: – Small impact on the traced system, fast, user- oriented features. ● Interfacing with: Common Trace Format (CTF) Interoperability Between Tracing Tools Tracing Well With Others: Integration with the Common Trace Format (CTF), of GDB Tracepoints Into Trace Tools, Mathieu Desnoyers, EfficiOS, Stan Shebs, Mentor Graphics,
    [Show full text]
  • Reverse Engineering Digital Forensics Rodrigo Lopes October 22, 2006
    Reverse Engineering Digital Forensics Rodrigo Lopes October 22, 2006 Introduction Engineering is many times described as making practical application of the knowledge of pure sciences in the solution of a problem or the application of scientific and mathematical principles to develop economical solutions to technical problems, creating products, facilities, and structures that are useful to people. What if the opposite occurs? There is some product that may be a solution to some problem but the inner workings of the solution or even the problem it addresses may be unknown. Reverse engineering is the process of analyzing and understanding a product which functioning and purpose are unknown. In Computer Science in particular, reverse engineering may be defined as the process of analyzing a system's code, documentation, and behavior to identify its current components and their dependencies to extract and create system abstractions and design information. The subject system is not altered; however, additional knowledge about the system is produced. The definition of Reverse Engineering is not peaceful though, especially when it concerns to court and lawsuits. The Reverse Engineering of products protected by copyrighting may be a crime, even if no code is copied. From the software companies’ point of view, Reverse Engineering is many times defined as “Analyzing a product or other output of a process in order to determine how to duplicate the know-how which has been used to create a product or process”. Scope and Goals In the Digital Forensics’ scope, reverse engineering can directly be applied to analyzing unknown and suspicious code in the system, to understand both its goal and inner functioning.
    [Show full text]
  • Linux Performance Tools
    Linux Performance Tools Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg This Tutorial • A tour of many Linux performance tools – To show you what can be done – With guidance for how to do it • This includes objectives, discussion, live demos – See the video of this tutorial Observability Benchmarking Tuning Stac Tuning • Massive AWS EC2 Linux cloud – 10s of thousands of cloud instances • FreeBSD for content delivery – ~33% of US Internet traffic at night • Over 50M subscribers – Recently launched in ANZ • Use Linux server tools as needed – After cloud monitoring (Atlas, etc.) and instance monitoring (Vector) tools Agenda • Methodologies • Tools • Tool Types: – Observability – Benchmarking – Tuning – Static • Profiling • Tracing Methodologies Methodologies • Objectives: – Recognize the Streetlight Anti-Method – Perform the Workload Characterization Method – Perform the USE Method – Learn how to start with the questions, before using tools – Be aware of other methodologies My system is slow… DEMO & DISCUSSION Methodologies • There are dozens of performance tools for Linux – Packages: sysstat, procps, coreutils, … – Commercial products • Methodologies can provide guidance for choosing and using tools effectively • A starting point, a process, and an ending point An#-Methodologies • The lack of a deliberate methodology… Street Light An<-Method 1. Pick observability tools that are: – Familiar – Found on the Internet – Found at random 2. Run tools 3. Look for obvious issues Drunk Man An<-Method • Tune things at random until the problem goes away Blame Someone Else An<-Method 1. Find a system or environment component you are not responsible for 2. Hypothesize that the issue is with that component 3. Redirect the issue to the responsible team 4.
    [Show full text]
  • Advanced Linux Tracing Technologies for Online Surveillance of Software Systems
    Advanced Linux tracing technologies for Online Surveillance of Software Systems M. Couture DRDC – Valcartier Research Centre Defence Research and Development Canada Scientific Report DRDC-RDDC-2015-R211 October 2015 © Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2015 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2015 Abstract This scientific report provides a description of the concepts and technologies that were developed in the Poly-Tracing Project. The main product that was made available at the end of this four-year project is a new software tracer called Linux Trace Toolkit next generation (LTTng). LTTng actually represents the centre of gravity around which much more applied research and development took place in the project. As shown in this document, the technologies that were produced allow the exploitation of the LTTng tracer and its output for two main purposes: a- solving today’s increasingly complex software bugs and b- improving the detection of anomalies within live information systems. This new technology will enable the development of a set of new tools to help detect the presence of malware and malicious activity within information systems during operations. Significance to defence and security All the technologies described in this document result from collaborative R&D efforts (the Poly-Tracing project), which involved the participation of NSERC, Ericsson Canada, DRDC – Valcartier Research Centre, and the following Canadian universities: Montreal Polytechnique, Laval University, Concordia University, and the University of Ottawa. This scientific report should be considered as one of the Platform-to-Assembly Secured Systems (PASS) deliverables.
    [Show full text]
  • 245533753-MIT.Pdf
    THE VULNERABILITY OF TECHNICAL SECRETS TO REVERSE ENGINEERING: IMPLICATIONS FOR COMPANY POLICY By Cenkhan Kodak M.S. in Electrical and Computer Systems Engineering (2001) University of Massachusetts at Amherst Submitted to the Systems Design and Management Program In partial fulfillment of the requirements for the degree of Master of Science in Engineering and Management At the MASSACHUSETTS INSTITUTE OF TECHNOLOGY FEBRUARY 2008 © 2008 Cenkhan Kodak. All rights reserved. The author hereby grants to MIT permission to reproduce and Distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created Signature of the Author: m- /7 Systems Desigq and Management Program r\ Ja iry 2008 Certified by: 7 Professoi ,ric von Hippel Thesis Supervisor, MIT mSchgQl o•.Ma genfer t Certified by: MASSACHUSES INSTITUTE= Pat Hale OF TEOHiNOLOGY Director, Systems Design and Management Program MAY 0 6 2008 I-I .a,:IARCHIVES -2- THE VULNERABILITY OF TECHNICAL SECRETS TO REVERSE ENGINEERING: IMPLICATIONS FOR COMPANY POLICY By Cenkhan Kodak Submitted to the Systems Design and Engineering Program On February 04 2008, in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management Abstract In this thesis I will explore the controversial topic of reverse engineering, illustrating with case examples drawn from the data storage industry. I will explore intellectual property rights issues including, users' fair-use provisions that permit reverse engineering. I will also explore the nature of the practice via several types of analyses including: the costs and benefits of reverse engineering; the practical limitations of reverse engineering; and a layered approach to reverse engineering as it applies to complex systems.
    [Show full text]
  • Powerful Software Analysis System-Wide Tracing Is Here
    DATASHEET Powerful Software Analysis Benefits Software tracing is an efficient way to record information about a program’s execution. Programmers, TRACEexperienced system administrators, and technical supportCOMPASS personnel use • Faster resolution of complex problems it to diagnose problems, tune for performance, and improve • Clear understanding of system behaviour comprehension of system behavior. Trace Compass facilitates the visualization and analysis of traces and logs • System performance optimization from multiple sources; it enables diagnostic and monitoring • Adds value in many stages of a product’s operations from a simple device to an entire cloud. life cycle: development, test, production • Facilitates the addition of new parsers, analyses, and views to solve specific issues System-Wide Tracing is here • Scales to GBs of compact binary trace Trace Compass can take multiple traces and logs from • Correlate traces from different nodes in a different sources and formats, and merge them into a single cloud with trace synchronization event stream that allows system-wide tracing. It is possible to correlate application, virtual machine, operating systems, • Multi-platform: Linux, Windows, MacOSX. bare metal, and hardware traces and to display the results together, delivering unprecedented insight into your entire system. Overview • Can be integrated into Eclipse IDE or used as a standalone application. Eclipse plug-ins facilitates the addition of new analysis and views. • Provides an extensible framework written in Java that exposes a generic interface for integration of logs or trace data input. • Custom text or XML parsers can be added directly from the graphical interface by the user. • Extendable to support various proprietary log or trace files.
    [Show full text]
  • Software Security and Reverse Engineering
    Software Security and Reverse Engineering What is reverse engineering? Today the market of software is covered by an incredible number of protected applications, which don't allow you to use all features of programs if you aren't a registered user of these. Reverse engineering is simply the art of removing protection from programs also known as “cracking”. In Some other words cracking is described as follows: - “When you create a program you engineer it, in fact you build the executable from the source-code. The reverse engineering is simply the art of generate a source-code from an executable. Reverse engineering is used to understand how a program does an action, to bypass protection etc. Usually it's not necessary to disassemble all code of the application not only the part of the application that we are interested must be reversed. Reverse engineering used by a cracker to understand the protection scheme and to break it, so it's a very important thing in the whole world of the crack.” In short: - "Reverse Engineering referred to a way to modify a program such that it behaves as the way a reverse engineer wish." “Cracking is a method of making a software program function other than it was Originally intended by means of investigating the code, and, if necessary, patching It.” A Little bit of history Reveres egg. Most probably start with the DOS based computer games. The aim is that a player has full life and armed in the final stage of the game. So what a reverse egg.
    [Show full text]
  • Soft Robotic Hand Prosthesis Using Reverse Engineering and Fast Prototyping
    Proceedings of the 1 st Iberic Conference on Theoretical and Experimental Mechanics and Materials / 11 th National Congress on Experimental Mechanics. Porto/Portugal 4-7 November 2018. Ed. J.F. Silva Gomes. INEGI/FEUP (2018); ISBN: 978-989-20-8771-9; pp. 953-966. PAPER REF: 7452 SOFT ROBOTIC HAND PROSTHESIS USING REVERSE ENGINEERING AND FAST PROTOTYPING Hugo D’Almeida, Tiago Charters, Paulo Almeida, Mário J.G.C. Mendes (*) Instituto Superior de Engenharia de Lisboa (ISEL), Instituto Politécnico de Lisboa, Lisboa, Portugal (*) Email: [email protected] ABSTRACT The present work aimed to develop a soft robotic prosthesis of the human hand using reverse engineering and fast prototyping. This project arises in response to some limitations of the current conventional prostheses, namely aesthetic, mechanical and cost, that fail to fulfil the needs of its users, for example with soft objects. The hand prosthesis design involved the acquisition and processing of a medical image of the user's hand, followed by a modelling process which proved to be highly complex, and finally the obtainment of a real model (by 3D printing) of the prosthesis. The results obtained proved to be satisfactory in the approximation of the hand morphology, low cost and the designed mechanical properties. However, due to some technological limitations (the used 3D printers), and more specifically in the physical conception of the model, its functionality is yet to be proved with the pneumatic control. Keywords: Soft robotics, reverse engineering, fast prototyping, hand prosthesis. INTRODUCTION The human hand can be considered the most used tool by the man in the execution of the daily tasks, and its loss leads to physical and psychological damages.
    [Show full text]
  • Reverse Engineering Is Reverse Forward Engineering)
    RE- ENGINEERING The reengineering of software was described by Chikofsky and Cross in their 1990 paper, as "The examination and alteration of a system to reconstitute it in a new form" . Less formally, reengineering is the modification of a software system that takes place after it has been reverse engineered, generally to add new functionality, or to correct errors. This entire process is often erroneously referred to as reverse engineering; however, it is more accurate to say that reverse engineering is the initial examination of the system, and reengineering is the subsequent modification. Re-engineering is mostly used in the context where a legacy system is involved. Software systems are evolving on high rate because there more research to make the better so therefore software system in most cases, legacy software needs to operate on a new computing platform. 'Re-engineering' is a set of activities that are carried out to re-structure a legacy system to a new system with better functionalities and conform to the hardware and software quality constraint. FORWARD ENGINEERING Forward engineering is the opposite of reverse engineering. In forward engineering, one takes a set of primitives of interest, builds them into a working system, and then observes what the system can and cannot do. Forward engineering is the foundation of synthetic psychology (Braitenberg, 1984; Dawson, 2004; Pfeifer & Scheier, 1999). Braitenberg has argued that forward engineering is likely to produce simpler theories than reverse engineering because the latter tends to attribute behavioural complexities to the internal mechanisms of the agent. Braitenberg calls this the law of uphill analysis and downhill synthesis.
    [Show full text]
  • Fine-Grained Distributed Application Monitoring Using Lttng
    OSSOSS EuropeEurope 20182018 Fine-grained Distributed Application Monitoring Using LTTng [email protected] jgalar PresenterPresenter Jérémie Galarneau EfficiOS Inc. – Vice President – http://www.efficios.com Maintainer of – LTTng-tools – Babeltrace OSS Europe 2018 2 OutlineOutline A few words about tracing and LTTng The (long) road to session rotation mode How session rotation mode makes distributed trace analyses possible (and how to implement them) OSS Europe 2018 3 Isn’tIsn’t tracingtracing justjust anotheranother namename forfor logging?logging? Tracers are not completely unlike loggers Both save information used to understand the state of an application – Trying to cater to developers, admins, and end-users In both cases, a careful balance must be achieved between verbosity, performance impact, and usefulness – Logging levels – Enabling only certain events OSS Europe 2018 4 DifferentDifferent goals,goals, differentdifferent tradeoffstradeoffs Tracers tend to focus on low-level events – Capture syscalls, scheduling, filesystem events, etc. – More events to capture means we must lower the space and run-time cost per event – Binary format – Different tracers use different strategies to minimize cost OSS Europe 2018 5 DifferentDifferent goals,goals, differentdifferent tradeoffstradeoffs Traces are harder to work with than text log files – File size ● Idle 4-core laptop: 54k events/sec @ 2.2 MB/sec ● Busy 8-core server: 2.7M events/sec @ 95 MB/sec – Exploration can be difficult – Must know the application or kernel to
    [Show full text]