Finding Memory Leaks and Errors in Parallel Applications
Total Page:16
File Type:pdf, Size:1020Kb
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. -
Defeating Memory Corruption Attacks Via Pointer Taintedness Detection
Defeating Memory Corruption Attacks via Pointer Taintedness Detection Shuo Chen †, Jun Xu ‡, Nithin Nakka †, Zbigniew Kalbarczyk †, Ravishankar K. Iyer † † Center for Reliable and High-Performance Computing, ‡ Department of Computer Science University of Illinois at Urbana-Champaign, North Carolina State University 1308 W. Main Street, Urbana, IL 61801 Raleigh, NC 27695 {shuochen, nakka, kalbar, iyer}@crhc.uiuc.edu [email protected] Abstract formal methods have been adopted to prevent Most malicious attacks compromise system security programmers from writing insecure software. But despite through memory corruption exploits. Recently proposed substantial research and investment, the state of the art is techniques attempt to defeat these attacks by protecting far from perfect, and as a result, security vulnerabilities are program control data. We have constructed a new class of constantly being discovered in the field. The most direct attacks that can compromise network applications without counter-measure against vulnerabilities in the field is tampering with any control data. These non-control data security patching. Patching, however, is reactive in nature attacks represent a new challenge to system security. In and can only be applied to known vulnerabilities. The long this paper, we propose an architectural technique to latency between bug discovery and patching allows defeat both control data and non-control data attacks attackers to compromise many unpatched systems. An based on the notion of pointer taintedness . A pointer is alternative to patching is runtime vulnerability masking said to be tainted if user input can be used as the pointer that can stop ongoing attacks. Compiler and library value. A security attack is detected whenever a tainted interception techniques have been proposed to mask value is dereferenced during program execution. -
Representing and Reasoning About Dynamic Code
Representing and reasoning about dynamic code Item Type Proceedings Authors Bartels, Jesse; Stephens, Jon; Debray, Saumya Citation Bartels, J., Stephens, J., & Debray, S. (2020, September). Representing and Reasoning about Dynamic Code. In 2020 35th IEEE/ACM International Conference on Automated Software Engineering (ASE) (pp. 312-323). IEEE. DOI 10.1145/3324884.3416542 Publisher ACM Journal Proceedings - 2020 35th IEEE/ACM International Conference on Automated Software Engineering, ASE 2020 Rights © 2020 Association for Computing Machinery. Download date 23/09/2021 23:26:56 Item License http://rightsstatements.org/vocab/InC/1.0/ Version Final accepted manuscript Link to Item http://hdl.handle.net/10150/652285 Representing and Reasoning about Dynamic Code Jesse Bartels Jon Stephens Saumya Debray Department of Computer Science Department of Computer Science Department of Computer Science The University Of Arizona University Of Texas The University Of Arizona Tucson, AZ 85721, USA Austin, TX 78712, USA Tucson, AZ 85721, USA [email protected] [email protected] [email protected] ABSTRACT and trace dependencies back, into and through the JIT compiler’s Dynamic code, i.e., code that is created or modified at runtime, is code, to understand the data and control flows that influenced the ubiquitous in today’s world. The behavior of dynamic code can JIT compiler’s actions and caused the generation of the problem- depend on the logic of the dynamic code generator in subtle and non- atic code. E.g., for the CVE-2017-5121 bug mentioned above, we obvious ways, e.g., JIT compiler bugs can lead to exploitable vul- might want to perform automated analyses to identify which anal- nerabilities in the resulting JIT-compiled code. -
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. -
Ben Livshits 1 Basic Instrumentation
Runtime monitoring CO444H Ben Livshits 1 Basic Instrumentation • Insert additional code into the program • This code is designed to record important events as they occur at runtime • Some examples • A particular function is being hit or a statement is being hit • This leads to function-level or line-level coverage • Each allocation to measure overall memory allocation 2 Levels of Instrumentation • Native code • Instrument machine code • Tools like LLVM are often used for rewriting • Bytecode • Common for languages such as Java and C# • A variety of tools are available for each bytecode format • JoeQ is in this category as well, although it’s a lot more general • Source code • Common for languages like JavaScript • Often the easiest option – parse the code and add more statements 3 Runtime Code Monitoring •Three major examples of monitoring • Purify/Valgrind • Detecting data races • Detecting memory leaks 4 5 Memory Error Detection Purify • C and C++ are not type-safe • The type system and the runtime fail to enforce type safety • What are some of the examples? • Possible to read and write outside of your intended data structures • Write beyond loop bounds • Or object bounds • Or overwrite the code pointer, etc. 6 Track Each Byte of Memory • Three states for every byte of tracker memory • Unallocated: cannot be read or written • Allocated but not initialized: cannot be read • Allocated and initialized: all operations are allowed 7 Instrumentation for Purify • Check the state of each byte at every access • Binary instrumentation: • Add -
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 -
Memory Safety Without Garbage Collection for Embedded Applications
Memory Safety Without Garbage Collection for Embedded Applications DINAKAR DHURJATI, SUMANT KOWSHIK, VIKRAM ADVE, and CHRIS LATTNER University of Illinois at Urbana-Champaign Traditional approaches to enforcing memory safety of programs rely heavily on run-time checks of memory accesses and on garbage collection, both of which are unattractive for embedded ap- plications. The goal of our work is to develop advanced compiler techniques for enforcing memory safety with minimal run-time overheads. In this paper, we describe a set of compiler techniques that, together with minor semantic restrictions on C programs and no new syntax, ensure memory safety and provide most of the error-detection capabilities of type-safe languages, without using garbage collection, and with no run-time software checks, (on systems with standard hardware support for memory management). The language permits arbitrary pointer-based data structures, explicit deallocation of dynamically allocated memory, and restricted array operations. One of the key results of this paper is a compiler technique that ensures that dereferencing dangling pointers to freed memory does not violate memory safety, without annotations, run-time checks, or garbage collection, and works for arbitrary type-safe C programs. Furthermore, we present a new inter- procedural analysis for static array bounds checking under certain assumptions. For a diverse set of embedded C programs, we show that we are able to ensure memory safety of pointer and dy- namic memory usage in all these programs with no run-time software checks (on systems with standard hardware memory protection), requiring only minor restructuring to conform to simple type restrictions. Static array bounds checking fails for roughly half the programs we study due to complex array references, and these are the only cases where explicit run-time software checks would be needed under our language and system assumptions. -
Memory Leak Or Dangling Pointer
Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer. -
Effective and Efficient Memory Protection Using Dynamic Tainting
1 Effective and Efficient Memory Protection Using Dynamic Tainting Ioannis Doudalis, Student Member, IEEE, James Clause, Member, IEEE, Guru Venkataramani, Member, IEEE, Milos Prvulovic, Senior Member, IEEE, and Alessandro Orso, Member, IEEE, ! Abstract—Programs written in languages allowing direct access to pointer p or a pointer derived from p and 2) if the access memory through pointers often contain memory-related faults, which occurs during the interval when p is valid, (i.e. between the cause non-deterministic failures and security vulnerabilities. We present allocation and deallocation of m). All other accesses to m are a new dynamic tainting technique to detect illegal memory accesses. illegal memory accesses (IMAs), where a pointer is used to When memory is allocated, at runtime, we taint both the memory and the corresponding pointer using the same taint mark. Taint marks access memory outside the bounds of the memory area with are then propagated and checked every time a memory address m which it was originally associated, or outside the time period is accessed through a pointer p; if the associated taint marks differ, during which the pointer is valid. an illegal access is reported. To allow always-on checking using a IMAs are especially relevant for several reasons. First, they low-overhead, hardware-assisted implementation, we make several key are caused by typical programming errors, such as array-out- technical decisions. We use a configurable, low number of reusable taint of-bounds accesses and stale pointer dereferences, and are thus marks instead of a unique mark for each allocated area of memory, reducing the performance overhead without losing the ability to target widespread and common. -
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. -
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. -
Tutorial on Debugging, Memory Leaks and Profiling
High Performance Computing for Science and Engineering I Tutorial on debugging, memory leaks and profiling Michalis Chatzimanolakis Computational Science & Engineering Laboratory OUTLINE - Approaches to debug your code •Using assertions •Using a debugger •Memory sanitation •Using a profiler Assertions in C++ An assertion is a logical statement that will cause your code to abort execution, if it is false. Example: Assertions can affect performance, Assertions perform checks that make sure that as they are essentially ‘if’ statements. some conditions are met. However, it is good practice to add assertions in a code. A simple compilation flag can ignore all assertions, so it is generally a good idea to use them. It is useful to combine assertions with the std functions isinf and isnan They can also be used with screen output. Compiler warnings Compiler warnings are compilation flags that you can (should) add to your Makefiles. Enabling warnings makes the compiler check for several issues in your source file, such as: • Forgetting to initialize a variable • Not using a declared variable • Using a function before declaring it • Having screen/file output with incorrect format (for example, treating doubles as integers) Generally, you should add warnings and try to fix all of them, before proceeding with further debugging your code. Note that different compilers may produce different warnings. The most common compiler warning flags are listed below: -Wall : enables several construction/declaration warnings -Wextra : more warnings than Wall including warnings for unused variables -Werror: will treat all warnings as errors -Wpedantic: warnings related to the use of non standard C++ extensions Using a debugger What is a debugger? A debugger is a program.