Memory Troubleshooting Valgrind

Memory Troubleshooter---Valgrind

• 1. Overview
• 2. Valgrind
• 3. Memory Leak monitoring
  • 3.1. Sample code
  • 3.2. Compile it
  • 3.3. Using Valgrind to monitor memory leaks in processes
• 4. Hanging hands
  • 4.1. Sample Code
  • 4.2. Valgrind Run Results
• 5. Release the same pointer multiple times
  • 5.1. Sample Code
  • 5.2. Valgrind Monitoring
• 6. Advantages and disadvantages of Valgrind
  • 6.1. Advantages
  • 6.2. Disadvantages
• 7. Other tools for Valgrind
  • 7.1. Cachegrind
  • 7.2. Callgrind
  • 7.3. Helgrind
  • 7.4. DRD
  • 7.5. Massif
  • 7.6. Dhat
• 8. Reference

1 Overview

The following three memory problems often occur when programming in C + +:

• Memory leaks
• Hanging hands
• Release the same piece of memory multiple times

This series of articles provides a brief introduction to the tools and methods for troubleshooting these three issues, first look at Valgrind

2 Valgrind

The Valgrind is a tool to monitor memory usage and monitor memory leaks. For some applications that are not large in size, Valgrind is a powerful tool.

3 memory leak monitoring3.1 Sample Code

1:int Main () 2: { 3:     char *p = malloc (sizeof (char) *); 4:     if (p = = NULL) { 5:         return 0;
        
          6:}
          8: *p++ = ' a '; 9: *p++ = ' B ';  11:printf ("%s\n", *p); 13:return 0; :}     
           

3.2 Compiling it

1:gcc-g-O core1 core1.c

3.3 Memory leak monitoring process with Valgrind

1:valgrind--leak-check=yes--show-reachable=yes./core

The output of the Valgrind is:

1: ==25500== Memcheck, a memory error detector2: ==25500== Copyright (C) 2002-2009, and GNU GPL ' d, by Julian Seward et al.3: ==25500== Using Valgrind-3.5.0 and Libvex; Rerun with-h for copyright info4: ==25500== Command:./core15: ==25500==6: ==25500== Conditional Jump or move depends on uninitialised value (s)7: ==25500== at 0x36a104546a:vfprintf (in/lib64/libc-2.12.so)8: ==25500== by 0x36a104eac9:printf (in/lib64/libc-2.12.so)9: ==25500== by 0x40055d:main (core1.c:13)10: ==25500==One by one: (NULL)12: ==25500==: ==25500== HEAP SUMMARY:+: ==25500== in use with exit:10 bytes in 1 blocks==25500== Total heap Usage:1 allocs, 0 frees, Bytes allocated16: ==25500==: ==25500== bytes in 1 blocks is definitely lost in loss record 1 of 118: ==25500== at 0x4a0515d:malloc (vg_replace_malloc.c:195)  19: ==25500== by 0x400515:main (core1.c:5) 20: ==25500==21: ==25500== LEAK SUMMARY:22: ==25500== definitely lost:10 bytes in 1 blocks23: ==25500== indirectly lost:0 by TES in 0 blocks24: ==25500== possibly lost:0 bytes in 0 blocks25: ==25500== STI ll reachable:0 bytes in 0 blocks26: ==25500== suppressed:0 bytes in 0 blocks27 : ==25500==28: ==25500== for counts of detected and suppressed errors, rerun with:-v29: ==25500== use--track-origins=yes to see where uninitialised values come from30: ==25500== E Rror Summary:2 errors from 2 contexts (Suppressed:6 from 6)         span>    

As you can see, valgrind hints that the memory allocated on line fifth is not released

4 Hanging hands4.1 Sample Code

1:struct Elem { 2:int A;  3:double B;  4:};  5:  6:int main ()  7: { 8:struct Elem *e = malloc (sizeof (struct elem));  9:if (E = = NULL) {10:return 0; One:}12: 13:e->a = 10; 14:e->b = 10.10; 15: 16:double *xx = &e->b; : 18:printf ("%f\n", *xx);  : 20:free (e); 22:printf ("%f\n", *xx); 24:return 0; :}                 

4.2 Valgrind Run Results

Similarly, the result of the Valgrind operation is compiled with-G:

1: [[email protected]]$ valgrind--leak-check=yes--show-reachable=yes./core22: ==26148== Memcheck, a memory error detector3: ==26148== Copyright (C) 2002-2009, and GNU GPL ' d, by Julian Seward et al.4: ==26148== Using Valgrind-3.5.0 and Libvex; Rerun with-h for copyright info5: ==26148== Command:./core26: ==26148==7:10.18: ==26148== Invalid read of size 89: ==26148== at 0x4005ca:main (core2.c:26)10: ==26148== Address 0x502a048 is 8 bytes inside a block of size + free ' d 11: = =26148== at 0x4a04d72:free (vg_replace_malloc.c:325) 12: ==26148== by 0x4005c5:main (core2.c:24) Span class= "Linenr" >13: ==26148==14:10.10000015: ==26148==16: ==26148== HEAP summary:17: ==26148== in use with exit:0 bytes in 0 blocks18: ==26148== Total Heap Usage:1 Allocs, 1 frees, bytes Allocated19: ==26148==20: ==26148== all heap blocks were freed--no leaks is Possible21: ==26148==22: ==26148== for counts of detected and suppressed errors, rerun with:-v23: ==26148== ERROR SUM Mary:1 errors from 1 contexts (Suppressed:6 from 6)          span>    

You can see that after free (e), the pointer xx becomes the hanging pointer, and thereafter the reading of XX, if the memory that XX points to has not been glibc recycled, the process will not be core off. Valgrind hint in 26 lines did the Invalid read for XX.

5 Releasing the same pointer multiple times5.1 Sample Code

1:int Main () 2: { 3:     char *p = malloc (sizeof (char) *); 4:     if (p = = NULL) { 5:         return 0;
        
          6:}
          8:char *q = p;  Ten: *p++ = ' a '; One : *p++ = ' B '; 13:printf ("%s\n", *p); 15:free (P); 16:free (q); 17:return 0; :}        
           

5.2 Valgrind Monitoring

1: [[email protected]]$ valgrind--leak-check=yes--show-reachable=yes./core12: ==26874== Memcheck, a memory error detector3: ==26874== Copyright (C) 2002-2009, and GNU GPL ' d, by Julian Seward et al.4: ==26874== Using Valgrind-3.5.0 and Libvex; Rerun with-h for copyright info5: ==26874== Command:./core16: ==26874==7: ==26874== Conditional Jump or move depends on uninitialised value (s)8: ==26874== at 0x36a104546a:vfprintf (in/lib64/libc-2.12.so)9: ==26874== by 0x36a104eac9:printf (in/lib64/libc-2.12.so)Ten: ==26874== by 0x4005b5:main (core1.c:15)11: ==26874==: (NULL): ==26874== Invalid Free ()/delete/delete[]: ==26874== at 0x4a04d72:free (vg_replace_malloc.c:325): ==26874== by 0x4005c1:main (core1.c:17): ==26874== Address 0x502a042 is 2 bytes inside a block of size ten alloc ' d17: ==26874== at 0x4a0515d:malloc (vg_replace_malloc.c:195)  18: ==26874== by 0x400565:main (core1.c:5) 19: ==26874== 20: ==26874== 21: ==26874== HEAP summary:22: ==26874== in use with exit:0 bytes in 0 blocks
                         
                          23: ==26874== Total Heap Usage:1 Allocs, 2 frees, bytes Allocated
                          24: ==26874==25: ==26874== all heap blocks were freed--no leaks is Possible26: ==26874==
                             
                              27: ==26874== for counts of detected and suppressed errors, rerun with:-v
                               28: ==2687 4== use--track-origins=yes to see where uninitialised values come from29: ==26874== ERROR summary:2 Errors from 2 contexts (Suppressed:6 from 6)   
                              
                           
                              / span>  

As you can see, the VALGRIND hint has a invalid free () on line 17

6 Advantages and disadvantages of Valgrind

Valgrind uses the Memcheck tool to do memory monitoring by default.

6.1 Advantages

Use Valgrind to monitor memory leaks without recompiling the application without re-linking the application without making any changes to the application process. If you want to see detailed error messages, just add the-G option at compile time.

6.2 Disadvantages

Whether Valgrind uses the Memcheck tool to monitor memory, it takes over the application and reads debug information from the application executable and library files to display a detailed error location. When Valgrind is started, the application process is actually executed in the Valgrind virtual environment, Valgrind passes each line of code to the Memcheck tool, memcheck the tool to add its own debugging information, and then actually runs the synthesized code. The Memcheck tool adds additional statistical code to the application process for each anti-save operation and each variable assignment operation, and typically, the application runs at approximately 10-50 times slower than the native code after using the Memcheck tool.

Second, for some non-stop running server program memory problems, Valgrind powerless. Not only because Valgrind cannot stop it, it is also possible that the server process itself is designed to apply some memory that is as long as the life cycle of the process, never released, and that memory is Valgrind reported as a leak error.

Again, Valgrind support for multithreaded programs is not good enough. When multithreaded programs execute, valgrind only one thread at a time, and it does not take full advantage of multicore environments. When you run your multithreaded program with Valgrind, your valuable programs may run differently from running without using Valgrind.

7 other tools for Valgrind

In addition to the Memcheck tools, the Valgrind Toolkit has some other useful tools

7.1 Cachegrind

This tool simulates the first-level cache i1,d1 and L2 level two cache in the CPU, which accurately indicates the loss and hit of the cache in the program. It can also provide us with the number of cache misses, memory references, and each line of code, each function, each module, and the entire program, if needed. This is a great help in optimizing the program. See here for details.

7.2 Callgrind

Callgrind collects some data from the program runtime, functions call relationships and other information, and can optionally perform the cache simulation. At the end of the run, it writes the parsing data to a file. Callgrindannotate can convert the contents of this file into a readable form. See here for details.

7.3 Helgrind

It is primarily used to check for synchronization problems that occur in A/C + + multithreaded application (using POSIX threads). Helgrind looks for areas in memory that are accessed by multiple threads without a consistent lock, which are often places where threads are out of sync and can cause hard-to-dig errors. Helgrind implements a competitive detection algorithm called "Eraser", and makes further improvements to reduce the number of reported errors. See here for details.

7.4 DRD

This also enables a multi-threaded monitoring tool that provides more monitoring information than Helgrind. See here for details.

7.5 Massif

The stack analyzer, which measures how much memory the program uses in the stack. Tell us heap blocks, heap management blocks and stack sizes. Memcheck is not monitored for memory that is released by the application process but has not yet been returned to the operating system, and Massif is able to monitor this type of memory effectively. See here for details.

7.6 dhat

This tool can show in detail how the application process uses the stack to allow users to better evaluate the design of the program. See here for details.

8 References

• http://www.valgrind.org/

Author:cobbliu

Created:2015-04-14 Tue 01:19

Emacs 24.4.1 (ORG mode 8.2.10)

Validate

Categories: C, C + +, Linux programming technology, Linux system technology

Memory Troubleshooting Valgrind