DOCSLIB.ORG

Totalview® User Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Totalview® User Guide TotalView® User Guide Version 8.10 Copyright © 2010-2012 by Rogue Wave Software, Inc. All rights reserved. Copyright © 2007-2009 by TotalView Technologies, LLC Copyright © 1998–2007 by Etnus LLC. All rights reserved. Copyright © 1996–1998 by Dolphin Interconnect Solutions, Inc. Copyright © 1993–1996 by BBN Systems and Technologies, a division of BBN Corporation. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, pho- tocopying, recording, or otherwise without the prior written permission of Rogue Wave Software, Inc. ("Rogue Wave"). Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Rogue Wave has prepared this manual for the exclusive use of its custom- ers, personnel, and licensees. The information in this manual is subject to change without notice, and should not be construed as a commitment by Rogue Wave. Rogue Wave assumes no responsibility for any errors that appear in this document. TotalView and TotalView Technologies are registered trademarks of Rogue Wave Software, Inc. TVD is a trademark of Rogue Wave. Rogue Wave uses a modified version of the Microline widget library. Under the terms of its license, you are entitled to use these modifications. The source code is available at: http://www.roguewave.com/support/knowledge-base.aspx. All other brand names are the trademarks of their respective holders. ii Contents About This Guide 1 Content Organization 1 TotalView Family Differences 3 Using the CLI 4 Audience 5 Conventions 6 TotalView Documentation 7 Contacting Us 9 Part 1: Introduction 11 1 A Tour of TotalView 13 Basic Debugging with TotalView 13 TotalView Action Points vs. Print Statements 14 Examining Data 16 Simplifying Array Display 17 Seeing Groups of Variables 19 Setting Watchpoints 19 Debugging Multi-process and Multi-threaded Programs 20 Program Using Almost Any Execution Model 21 Supporting Multi-process and Multi-threaded Programs 21 Using Groups and Barriers 23 Memory Debugging 24 Introducing the CLI 24 What’s Next 24 2 About Threads, Processes, and Groups 25 A Couple of Processes 26 Threads 28 Complicated Programming Models 29 Types of Threads 31 Organizing Chaos 34 How TotalView Creates Groups 38 Simplifying What You’re Debugging 42 TotalView User Guide version 8.10 iii Part 2: Setting Up 45 3 Accessing TotalView Remotely 47 Using Remote Display 47 Remote Display Supported Platforms 47 Remote Display Components 47 Installing the Client 48 Installing on Linux 48 Installing on Microsoft Windows 49 Installing on Apple Mac OS X Intel 49 Sample Session 50 Advanced Options 52 Naming Intermediate Hosts 53 Submitting a Job to a Batch Queuing System 54 Setting Up Your Systems and Security 54 Session Profile Management 55 Sharing Profiles 55 Remote Display Server and Viewer 55 Batch Scripts 56 tv_PBS.csh Script 56 tv_LoadLeveler.csh Script 57 Remote Display Commands 58 Session Profiles Area 58 Remote Host and Routing Area 58 Product Area 60 Using the Submit to Batch Queuing System Entries 61 File > Profile > Save 61 File > Profile > Delete 62 File > Profile > Import 62 File > Profile > Export 62 File > Exit 62 4 Setting Up a Debugging Session 63 Compiling Programs 64 Using File Extensions 64 Starting TotalView 65 Initializing TotalView 68 Exiting from TotalView 70 Loading Programs 71 Loading Programs Using the GUI 71 Loading Programs Using the CLI 73 Attaching to Processes 73 Detaching from Processes 74 Examining Core Files 75 Setting Command-line Arguments and Environment Variables 77 Altering Standard I/O 78 Viewing Process and Thread States 79 Seeing Attached Process States 80 Seeing Unattached Process States 80 Handling Signals 82 iv Contents Setting Search Paths 85 Setting Startup Parameters 88 Setting Preferences 89 Setting Preferences, Options, and X Resources 95 5 Setting Up Remote Debugging Sessions 97 About Remote Debugging 97 Platform Issues when Remote Debugging 98 Automatically Launching a Process on a Remote Server 100 Troubleshooting Server Autolaunch 101 Changing the Remote Shell Command 101 Changing Arguments 102 Autolaunching Sequence 102 Starting the TotalView Server Manually 104 TotalView Server Launch Options and Commands 106 Server Launch Options 106 Setting Single-Process Server Launch Options 106 Setting Bulk Launch Window Options 107 Customizing Server Launch Commands 109 Setting the Single-Process Server Launch Command 109 Setting the Bulk Server Launch Command 110 Debugging Over a Serial Line 113 Starting the TotalView Debugger Server 113 6 Setting Up MPI Debugging Sessions 115 Debugging MPI Programs 116 Starting MPI Programs 116 Starting MPI Programs Using File > New Program 116 Debugging MPICH Applications 118 Starting TotalView on an MPICH Job 118 Attaching to an MPICH Job 119 Using MPICH P4 procgroup Files 121 Debugging MPICH2 Applications 122 Downloading and Configuring MPICH2 122 Starting TotalView Debugging on an MPICH2 Hydra Job 122 Starting TotalView Debugging on an MPICH2 MPD Job 123 Starting the MPI MPD Job with MPD Process Manager 123 Starting an MPICH2 MPD Job 123 Starting MPI Issues 125 MPI Rank Display 126 Displaying the Message Queue Graph Window 127 Displaying the Message Queue 130 About the Message Queue Display 130 Using Message Operations 131 Diving on MPI Processes 131 Diving on MPI Buffers 131 About Pending Receive Operations 132 About Unexpected Messages 132 About Pending Send Operations 132 Debugging Cray MPI Applications 133 Debugging IBM MPI Parallel Environment (PE) Applications 134 TotalView User Guide version 8.10 v Preparing to Debug a PE Application 134 Using Switch-Based Communications 134 Performing a Remote Login 135 Setting Timeouts 135 Starting TotalView on a PE Program 135 Setting Breakpoints 135 Starting Parallel Tasks 136 Attaching to a PE Job 136 Attaching from a Node Running poe 136 Attaching from a Node Not Running poe 136 Debugging IBM Blue Gene Applications 138 Debugging LAM/MPI Applications 139 Debugging QSW RMS Applications 140 Starting TotalView on an RMS Job 140 Attaching to an RMS Job 140 Debugging SiCortex MPI Applications 141 Debugging SGI MPI Applications 142 Starting TotalView on an SGI MPI Job 142 Attaching to an SGI MPI Job 142 Using ReplayEngine with SGI MPI 143 Debugging Sun MPI Applications 144 Attaching to a Sun MPI Job 144 Using ReplayEngine with Infiniband MPIs 145 Debugging Parallel Applications Tips 147 Attaching to Processes Tips 147 Parallel Debugging Tips 150 MPICH Debugging Tips 151 IBM PE Debugging Tips 152 7 Setting Up Parallel Debugging Sessions 153 Debugging OpenMP Applications 154 Debugging OpenMP Programs 154 About TotalView OpenMP Features 155 About OpenMP Platform Differences 156 Viewing OpenMP Private and Shared Variables 157 Viewing OpenMP THREADPRIVATE Common Blocks 158 Viewing the OpenMP Stack Parent Token Line 159 Using SLURM 160 Debugging IBM Cell Broadband Engine Programs 161 The PPU 162 The SPU 162 Cell Programing 162 PPU and SPU Executable Organization 163 PPU and SPU Executable Naming 163 Thread IDs 164 Breakpoints 164 Registers, Unions, and Casting 165 Debugging Cray XT Applications 167 Cray XT Catamount 167 Configuring Cray XT for TotalView 168 Using TotalView with your Cray XT System 169 vi Contents Cray XT CNL 169 Debugging SiCortex Applications 170 Installation Notes 170 Using TotalView on SiCortex 170 MPI Debugging 171 Debugging Global Arrays Applications 172 Debugging PVM (Parallel Virtual Machine) Applications 174 Supporting Multiple Sessions 174 Setting Up ORNL PVM Debugging 174 Starting an ORNL PVM Session 175 Automatically Acquiring PVM Processes 176 Attaching to PVM Tasks 176 About Reserved Message Tags 178 Cleaning Up Processes 178 Debugging Shared Memory (SHMEM) Code 179 Debugging UPC Programs 180 Invoking TotalView 180 Viewing Shared Objects 180 Displaying Pointer to Shared Variables 182 Part 3: Using the GUI 185 8 Using TotalView Windows 187 Using Mouse Buttons 188 Using the Root Window 189 Viewing Remote Processes 190 Viewing Data Linearly or Hierarchically 191 Controlling the Display of Processes and Threads 192 Using the Process Window 193 Viewing the Assembler Version of Your Code 196 Diving into Objects 199 Resizing and Positioning Windows and Dialog Boxes 202 Editing Text 203 Saving the Contents of Windows 204 9 Visualizing Programs and Data 205 Displaying Call Graphs 206 Parallel Backtrace View 208 Visualizing Array Data 210 Command Summary 210 How the Visualizer Works 211 Viewing Data Types in the Visualizer 211 Viewing Data 212 Visualizing Data Manually 212 Using the Visualizer 213 Using Dataset Window Commands 213 Using View Window Commands 214 Using the Graph Window 215 Displaying Graph Views 216 Using the Surface Window 217 Displaying Surface Views 218 TotalView User Guide version 8.10 vii Manipulating Surface Data 220 Visualizing Data Programmatically 221 Launching the Visualizer from the Command Line 222 Configuring TotalView to Launch the Visualizer 222 Setting the Visualizer Launch Command 223 You can preset the Visualizer launch options by setting X resources. Adapting a Third Party Visualizer 224 Part 4: Using the CLI 227 10 Using the Command Line Interface (CLI) 229 About the Tcl and the CLI 230 About The CLI and TotalView 230 Using the CLI Interface 231 Starting the CLI 232 Startup Example 232 Starting Your Program 233 About CLI Output 236 ‘more’ Processing 237 Using Command Arguments 238 Using Namespaces 239 About the CLI
Load more

Recommended publications
  • Memory Diagrams and Memory Debugging
    CSCI-1200 Data Structures | Spring 2020 Lab 4 | Memory Diagrams and Memory Debugging Checkpoint 1 (focusing on Memory Diagrams) will be available at the start of Wednesday's lab. Checkpoints 2 and 3 focus on using a memory debugger. It is highly recommended that you thoroughly read the instructions for Checkpoint 2 and Checkpoint 3 before starting. Memory debuggers will be a useful tool in many of the assignments this semester, and in C++ development if you work with the language outside of this course. While a traditional debugger lets you step through your code and examine variables, a memory debugger instead reports memory-related errors during execution and can help find memory leaks after your program has terminated. The next time you see a \segmentation fault", or it works on your machine but not on Submitty, try running a memory debugger! Please download the following 4 files needed for this lab: http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/buggy_lab4. cpp http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/first.txt http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/middle. txt http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/last.txt Checkpoint 2 estimate: 20-40 minutes For Checkpoint 2 of this lab, we will revisit the final checkpoint of the first lab of this course; only this time, we will heavily rely on dynamic memory to find the average and smallest number for a set of data from an input file. You will use a memory debugging tool such as DrMemory or Valgrind to fix memory errors and leaks in buggy lab4.cpp.
    [Show full text]
  • Automatic Detection of Uninitialized Variables
    Automatic Detection of Uninitialized Variables Thi Viet Nga Nguyen, Fran¸cois Irigoin, Corinne Ancourt, and Fabien Coelho Ecole des Mines de Paris, 77305 Fontainebleau, France {nguyen,irigoin,ancourt,coelho}@cri.ensmp.fr Abstract. One of the most common programming errors is the use of a variable before its definition. This undefined value may produce incorrect results, memory violations, unpredictable behaviors and program failure. To detect this kind of error, two approaches can be used: compile-time analysis and run-time checking. However, compile-time analysis is far from perfect because of complicated data and control flows as well as arrays with non-linear, indirection subscripts, etc. On the other hand, dynamic checking, although supported by hardware and compiler tech- niques, is costly due to heavy code instrumentation while information available at compile-time is not taken into account. This paper presents a combination of an efficient compile-time analysis and a source code instrumentation for run-time checking. All kinds of variables are checked by PIPS, a Fortran research compiler for program analyses, transformation, parallelization and verification. Uninitialized array elements are detected by using imported array region, an efficient inter-procedural array data flow analysis. If exact array regions cannot be computed and compile-time information is not sufficient, array elements are initialized to a special value and their utilization is accompanied by a value test to assert the legality of the access. In comparison to the dynamic instrumentation, our method greatly reduces the number of variables to be initialized and to be checked. Code instrumentation is only needed for some array sections, not for the whole array.
    [Show full text]
  • Memory Debugging
    Center for Information Services and High Performance Computing (ZIH) Memory Debugging HRSK Practical on Debugging, 03.04.2009 Zellescher Weg 12 Willers-Bau A106 Tel. +49 351 - 463 - 31945 Matthias Lieber ([email protected]) Tobias Hilbrich ([email protected]) Content Introduction Tools – Valgrind – DUMA Demo Exercise Memory Debugging 2 Memory Debugging Segmentation faults sometimes happen far behind the incorrect code Memory debuggers help to find the real cause of memory bugs Detect memory management bugs – Access non-allocated memory – Access memory out off allocated bounds – Memory leaks – when pointers to allocated areas get lost forever – etc. Different approaches – Valgrind: Simulation of the program run in a virtual machine which accurately observes memory operations – Libraries like ElectricFence, DMalloc, and DUMA: Replace memory management functions through own versions Memory Debugging 3 Memory Debugging with Valgrind Valgrind detects: – Use of uninitialized memory – Access free’d memory – Access memory out off allocated bounds – Access inappropriate areas on the stack – Memory leaks – Mismatched use of malloc and free (C, Fortran), new and delete (C++) – Wrong use of memcpy() and related functions Available on Deimos via – module load valgrind Simply run program under Valgrind: – valgrind ./myprog More Information: http://www.valgrind.org Memory Debugging 4 Memory Debugging with Valgrind Memory Debugging 5 Memory Debugging with DUMA DUMA detects: – Access memory out off allocated bounds – Using a
    [Show full text]
  • GC Assertions: Using the Garbage Collector to Check Heap Properties
    GC Assertions: Using the Garbage Collector to Check Heap Properties Edward Aftandilian Samuel Z. Guyer Tufts University Tufts University 161 College Ave 161 College Ave Medford MA Medford MA [email protected] [email protected] ABSTRACT The goal of this work is to develop a general mechanism, which GC assertion ex- This paper introduces GC assertions, a system interface that pro- we call a , that allows the programmer to express pected grammers can use to check for errors, such as data structure in- properties of data structures and convey this information to variant violations, and to diagnose performance problems, such as the garbage collector. The key is that many useful, non-trivial prop- memory leaks. GC assertions are checked by the garbage collec- erties can be easily checked by the garbage collector at GC time, tor, which is in a unique position to gather information and answer imposing little or no run-time overhead. The collector triggers the questions about the lifetime and connectivity of objects in the heap. assertion if it finds that the expected properties have been violated. We introduce several kinds of GC assertions, and we describe how While GC assertions require extra programmer effort, they cap- they are implemented in the collector. We also describe our report- ture application-specific properties that programmers want to check ing mechanism, which provides a complete path through the heap and can easily express. For example, we provide a GC assertion to to the offending objects. We show results for one type of asser- verify that a data structure is reclaimed at the next collection when tion that allows the programmer to indicate that an object should the programmer expects it to be garbage.
    [Show full text]
  • Heapviz: Interactive Heap Visualization for Program Understanding and Debugging
    Heapviz: Interactive Heap Visualization for Program Understanding and Debugging 1 Abstract Understanding the data structures in a program is crucial to understanding how the program works, or why it doesn’t work. Inspecting the code that implements the data structures, however, is an arduous task and often fails to yield insights into the global organization of a program’s data. Inspecting the actual contents of the heap solves these problems but presents a significant challenge of its own: finding an effective way to present the enormous number of objects it contains. In this paper we present Heapviz, a tool for visualizing and exploring snapshots of the heap obtained from a running Java program. Unlike existing tools, such as tra- ditional debuggers, Heapviz presents a global view of the program state as a graph, together with powerful interactive capabilities for navigating it. Our tool employs sev- eral key techniques that help manage the scale of the data. First, we reduce the size and complexity of the graph by using algorithms inspired by static shape analysis to aggregate the nodes that make up a data structure. Second, we implement a power- ful visualization component whose interactive interface provides extensive support for exploring the graph. The user can search for objects based on type, connectivity, and field values; group objects; and color or hide and show each group. The user may also inspect individual objects to see their field values and neighbors in the graph. These interactive abilities help the user manage the complexity of these huge graphs. By applying Heapviz to both constructed and real-world examples, we show that Heapviz provides programmers with a powerful and intuitive tool for exploring program behavior.
    [Show full text]
  • Efficient and Programmable Support for Memory Access Monitoring And
    Appears in the Proceedings of the 13th International Symposium on High-Performance Computer Architecture (HPCA-13), February 2007. MemTracker: Efficient and Programmable Support for Memory Access Monitoring and Debugging ∗ Guru Venkataramani Brandyn Roemer Yan Solihin Milos Prvulovic Georgia Tech Georgia Tech North Carolina State University Georgia Tech [email protected] [email protected] [email protected] [email protected] Abstract many of these tasks, performance overheads of such tools are prohibitive, especially in post-deployment monitoring of live Memory bugs are a broad class of bugs that is becoming (production) runs where end users are directly affected by the increasingly common with increasing software complexity, overheads of the monitoring scheme. and many of these bugs are also security vulnerabilities. Un- One particularly important and broad class of program- fortunately, existing software and even hardware approaches ming errors is erroneous use or management of memory for finding and identifying memory bugs have considerable (memory bugs). This class of errors includes pointer arith- performance overheads, target only a narrow class of bugs, metic errors, use of dangling pointers, reads from unini- are costly to implement, or use computational resources in- tialized locations, out-of-bounds accesses (e.g. buffer over- efficiently. flows), memory leaks, etc. Many software tools have been This paper describes MemTracker, a new hardware sup- developed to detect some of these errors. For example, Pu- port mechanism that can be configured to perform different rify [8] and Valgrind [13] detect memory leaks, accesses to kinds of memory access monitoring tasks. MemTracker as- unallocated memory, reads from uninitialized memory, and sociates each word of data in memory with a few bits of some dangling pointer and out-of-bounds accesses.
    [Show full text]
  • Secure Virtual Architecture: Using LLVM to Provide Memory Safety to the Entire Software Stack
    Secure Virtual Architecture: Using LLVM to Provide Memory Safety to the Entire Software Stack John Criswell, University of Illinois Andrew Lenharth, University of Illinois Dinakar Dhurjati, DoCoMo Communications Laboratories, USA Vikram Adve, University of Illinois What is Memory Safety? Intuitively, the guarantees provided by a safe programming language (e.g., Java, C#) Array indexing stays within object bounds No uses of uninitialized variables All operations are type safe No uses of dangling pointers Control flow obeys program semantics Sound operational semantics Benefits of Memory Safety for Commodity OS Code Security Memory error vulnerabilities in OS kernel code are a reality1 Novel Design Opportunities Safe kernel extensions (e.g. SPIN) Single address space OSs (e.g. Singularity) Develop New Solutions to Higher-Level Security Challenges Information flow policies Encoding security policies in type system 1. Month of Kernel Bugs (http://projects.info-pull.com/mokb/) Secure Virtual Architecture Commodity OS Virtual ISA Compiler + VM Hardware Native ISA Compiler-based virtual machine underneath software stack Uses analysis & transformation techniques from compilers Supports commodity operating systems (e.g., Linux) Typed virtual instruction set enables sophisticated program analysis Provide safe execution environment for commodity OSs Outline SVA Architecture SVA Safety Experimental Results SVA System Architecture Applications Safety Checking Compiler OS Kernel Drivers OS Memory Allocator SVA ISA Safety Verifier
    [Show full text]
  • Debugging Memory Problems on Cray XT Supercomputers with Totalview Debugger
    Debugging Memory Problems on Cray XT Supercomputers with TotalView Debugger Chris Gottbrath, Ariel Burton TotalView Technologies Robert Moench, Luiz DeRose Cray Inc. ABSTRACT: The TotalView Source Code Debugger gives scientists and engineers a way to debug memory problems on the Cray XT series supercomputer. Memory problems such as memory leaks, array bounds violations, and dangling pointers are difficult to track down with conventional tools on even a simple desktop architecture – they can be much more vexing when encountered on a distributed parallel architecture like that of the XT. KEYWORDS: Programming Environment Tools, Debuggers, Memory Debuggers, Cray XT Series 1. Introduction 2. Classes Of Memory Errors The purpose of this paper is to highlight the Programs typically make use of several different availability of memory debugging on the Cray XT series categories of memory that are managed in different supercomputer. Scientists and engineers taking ways. These include stack memory, heap memory, shared advantage of the unique capabilities of the Cray XT can memory, thread private memory and static or global now identify problems like memory leaks and heap memory. Programmers have to pay special attention, allocation bounds violations – problems that are though, to memory that is allocated out of the Heap extremely difficult and tedious to track down without the Memory. This is because the management of heap kinds of capabilities described here. memory is done explicitly in the program rather than implicitly at compile or run time. We begin by discussing and categorizing memory errors then provide a brief overview of both TotalView There are quite a number of ways that a program can Source Code Debugger and the Cray XT Series.
    [Show full text]
  • Detecting Memory Related Errors Using a Valgrind Tool Suite and Detecting Data Races Using Thread Sanitizer Clang
    Volume 6, No. 2, March-April 2015 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at www.ijarcs.info Detecting Memory Related Errors using a Valgrind Tool Suite and Detecting Data Races using Thread Sanitizer Clang Saroj. A.Shambharkar Kavikulguru Institute of Technology and Science Nagpur, India Abstract: It is important for a programmer to detect data races when a programming is done under concurrent systems or using shared memory or parallel programming. Many researchers are implementing their applications using the parallel programming and even for simple c programs ,they are not much concentrating on memory issues,accuracy of a result obtained, speed. It is important and one must take care it. There may found data races in their application code which has to be resolve and for that some data race detectors are required. There is also a need of detecting the memory related problems that may occur with shared memory. As a result of such memory related bugs and data races, the system may slow down the speed of the execution of a program .To improve the speed,the valgrind tool suite is used for memory related problems and ThreadSanitizer is used for detecting data races and some authors used Intel Thread Checker,ADAT,on-the-fly techniques for detecting them. Some tools are reducing the false positives but removing all false positives. Valgrind is providing a number of debugging and profiling tools that helps in improving the accuracy and to enhance the performance of system. This paper is demonstrating and showing the different results obtained by using the mentioned tool suite.
    [Show full text]
  • Introduction to C++ for Java Users
    Introduction Memory management Standard Template Library Classes and templates Introduction to C++ for Java users Leo Liberti DIX, Ecole´ Polytechnique, Palaiseau, France I semester 2006 Leo Liberti Introduction to C++ for Java users Introduction Programming style issues Memory management Main differences Standard Template Library Development of the first program Classes and templates Preliminary remarks Teachers Leo Liberti: [email protected]. TDs: Pietro Belotti [email protected], Claus Gwiggner [email protected] Aim of the course Introducing C++ to Java users Means Develop a simple C++ application which performs a complex task http://www.lix.polytechnique.fr/~liberti/teaching/c++/ fromjava/ Leo Liberti Introduction to C++ for Java users Introduction Programming style issues Memory management Main differences Standard Template Library Development of the first program Classes and templates Course structure Timetable Lecture: Wednesday 20/9/06 14:00-15:30, Amphi Pierre Curie TDs: 21-22/9: 8-10, 10:15-12:15, 13:45-15:45, 16-18, S.I. 34-35 25/9/06: 8-10, 10:15-12:15, S.I. 34-35 Course material (optional) Bjarne Stroustrup, The C++ Programming Language, 3rd edition, Addison-Wesley, Reading (MA), 1999 Stephen Dewhurst, C++ Gotchas: Avoiding common problems in coding and design, Addison-Wesley, Reading (MA), 2002 Herbert Schildt, C/C++ Programmer’s Reference, 2nd edition, Osborne McGraw-Hill, Berkeley (CA) Leo Liberti Introduction to C++ for Java users Introduction Programming style issues Memory management Main differences
    [Show full text]
  • Thread & Memory Debugger
    Thread & Memory Debugger Klaus-Dieter Oertel Intel IAGS HLRN User Workshop, 3-6 Nov 2020 Optimization Notice Copyright © 2020, Intel Corporation. All rights reserved. *Other names and brands may be claimed as the property of others. Debug Memory & Threading Errors Intel® Inspector Find and eliminate errors ▪ Memory leaks, invalid access… ▪ Races & deadlocks ▪ C, C++ and Fortran (or a mix) Simple, Reliable, Accurate ▪ No special recompiles Use any build, any compiler1 Clicking an error instantly displays source ▪ Analyzes dynamically generated or linked code code snippets and the call stack ▪ Inspects 3rd party libraries without source ▪ Productive user interface + debugger integration Fits your existing ▪ Command line for automated regression analysis process Optimization Notice 1That follows common OS standards. Copyright © 2020, Intel Corporation. All rights reserved. 3 *Other names and brands may be claimed as the property of others. Race Conditions Are Difficult to Diagnose They only occur occasionally and are difficult to reproduce Correct Incorrect Shared Shared Thread 1 Thread 2 Thread 1 Thread 2 Counter Counter 0 0 Read count 0 Read count 0 Increment 0 Read count 0 Write count ➔ 1 Increment 0 Read count 1 Increment 0 Increment 1 Write count ➔ 1 Write count ➔ 2 Write count ➔ 1 Optimization Notice Copyright © 2020, Intel Corporation. All rights reserved. 4 *Other names and brands may be claimed as the property of others. Deliver More Reliable Applications Intel® Inspector and Intel® Compiler Intel® Inspector Memory Errors Threading Errors ▪ Dynamic instrumentation ▪ No special builds ▪ Any compiler1 • Invalid Accesses • Races ▪ Source not required • Memory Leaks • Deadlocks • Uninit. Memory Accesses • Cross Stack References Intel® Compiler Pointer Errors ▪ Pointer checker • Out of bounds accesses • Dangling pointers ▪ Run time checks ▪ C, C++ Find errors earlier with less effort 1That follows common OS standards.
    [Show full text]
  • SCARPE: a Technique and Tool for Selective Capture and Replay of Program Executions∗
    SCARPE: A Technique and Tool for Selective Capture and Replay of Program Executions∗ Shrinivas Joshi Alessandro Orso Advanced Micro Devices Georgia Institute of Technology [email protected] [email protected] Abstract used. For another example, capture and replay would also allow for performing dynamic analyses that impose a high Because of software’s increasing dynamism and the het- overhead on the execution time. In this case, we could capture erogeneity of execution environments, the results of in-house executions of the uninstrumented program and then perform testing and maintenance are often not representative of the the expensive analyses off-line, while replaying. way the software behaves in the field. To alleviate this prob- State of the Art. Most existing capture-replay techniques lem, we present a technique for capturing and replaying par- and tools (e.g., WinRunner [17]) are defined to be used in- tial executions of deployed software. Our technique can be house, typically during testing. These techniques cannot used for various applications, including generation of test be used in the field, where many additional constraints ap- cases from user executions and post-mortem dynamic anal- ply. First, traditional techniques capture complete executions, ysis. We present our technique and tool, some possible appli- which may require to record and transfer a huge volume of cations, and a preliminary empirical evaluation that provides data for each execution. Second, existing techniques typi- initial evidence of the feasibility of our approach. cally capture inputs to an application, which can be difficult and may require ad-hoc mechanisms, depending on the way 1 Introduction the application interacts with its environment (e.g., via a net- Today’s software is increasingly dynamic, and its complexity work, through a GUI).
    [Show full text]