Use valgrind to check memory, valgrind to check memory
To do well, you must first sharpen your tools. Valgrind is a free and excellent toolkit. Most people usually use valgrind to detect memory problems, such as memory leakage and out-of-bounds. In fact, Valgrind is far more useful than this. It is actually a toolkit, in addition to checking memory problems, there are many other uses. I am going to give a general introduction to it. I don't want to introduce the usage of Valgrind in memory detection, but I want to explain it again. After all, this is one of the most famous uses of Valgrind. If it is missing, I am sorry, so let's take checking for memory problems as the first article. Take a look at the Code:
- # Include <stdlib. h>
- # Include <stdio. h>
- # Include <string. h>
- Static void mem_leak1 (void)
- {
- Char * p = malloc (1 );
- }
- Static void mem_leak2 (void)
- {
- FILE * fp = fopen ("test.txt", "w ");
- }
- Static void mem_overrun1 (void)
- {
- Char * p = malloc (1 );
- * (Short *) p = 2;
- Free (p );
- }
- Static void mem_overrun2 (void)
- {
- Char array [5];
- Strcpy (array, "hello ");
- }
- Static void mem_double_free (void)
- {
- Char * p = malloc (1 );
- Free (p );
- Free (p );
- }
- Static void mem_use_wild_pointer (void)
- {
- Char * p = (void *) 0x80184800;
- * P = 1;
- }
- Static void mem_free_wild_pointer (void)
- {
- Char * p;
- Free (p );
- }
- Int main ()
- {
- Mem_leak1 ();
- Mem_leak2 ();
- Mem_overrun1 ();
- Mem_overrun2 ();
- Mem_double_free ();
- // Mem_use_wild_pointer ();
- Mem_free_wild_pointer ();
- Return 0;
- }
Seven common memory problems are listed here: 1. dynamic Memory leakage; 2. resource leakage. The file descriptor is used as an example. 3. dynamic memory out of bounds; 4. array Memory out of bounds; 5. dynamic Memory double free; 6. use the wild pointer, that is, the uninitialized pointer; 7. release the wild pointer, that is, the uninitialized pointer. Because the code in this example is too simple, the use of the wild pointer in section 6th directly causes crash. Therefore, in main, the sample code is not actually called. Valgrind can only detect the code executed, so the following reports do not report 6th errors. However, in large projects, it is possible that the use of wild pointers will not cause crash. In addition, in the above 7 cases, some situations can be strictly stated as a category. The following describes how to execute valgrind to detect memory errors:
- Valgrind -- track-fds = yes -- leak-check = full -- undef-value-errors = yes./a. out
The specific meanings of the options above can be used in valgrind -- help. Some options are opened by default, but I am used to using option explicitly to show clarity. View the executed report:
- ==2326 = Memcheck, a memory error detector
- = 2326 = Copyright (C) 2002-2009, and gnu gpl 'd, by Julian Seward et al.
- = 2326 = Using Valgrind-3.5.0 and LibVEX; rerun with-h for copyright info
- = 2326 = Command:./a. out
- = 2326 =
- /* Dynamic memory out-of-bounds detected here, prompting Invalid write. */
- ==2326 = Invalid write of size 2
- = 2326 = at 0x80484B4: mem_overrun1 (in/home/fgao/works/test/a. out)
- ==2326 = by 0x8048553: main (in/home/fgao/works/test/a. out)
- = 2326 = Address 0x40211f0 is 0 bytes inside a block of size 1 alloc 'd
- = 2326 = at 0x4005BDC: malloc (vg_replace_malloc.c: 195)
- = 2326 = by 0x80484AD: mem_overrun1 (in/home/fgao/works/test/a. out)
- ==2326 = by 0x8048553: main (in/home/fgao/works/test/a. out)
- = 2326 =
/* Double free is detected here, prompting Invalid Free */
- ==2326 = Invalid free ()/delete []
- = 2326 = at 0x40057F6: free (vg_replace_malloc.c: 325)
- = 2326 = by 0x8048514: mem_double_free (in/home/fgao/works/test/a. out)
- ==2326 = by 0x804855D: main (in/home/fgao/works/test/a. out)
- ==2326 = Address 0x4021228 is 0 bytes inside a block of size 1 free 'd
- = 2326 = at 0x40057F6: free (vg_replace_malloc.c: 325)
- = 2326 = by 0x8048509: mem_double_free (in/home/fgao/works/test/a. out)
- ==2326 = by 0x804855D: main (in/home/fgao/works/test/a. out)
- = 2326 =
- /* Uninitialized variables are detected here */
- = 2326 = Conditional jump or move depends on uninitialised value (s)
- = 2326 = at 0x40057B6: free (vg_replace_malloc.c: 325)
- = 2326 = by 0x804853C: mem_free_wild_pointer (in/home/fgao/works/test/a. out)
- ==2326 = by 0x8048562: main (in/home/fgao/works/test/a. out)
- = 2326 =
/* Whether the wild pointer is illegal is detected here */
- ==2326 = Invalid free ()/delete []
- = 2326 = at 0x40057F6: free (vg_replace_malloc.c: 325)
- = 2326 = by 0x804853C: mem_free_wild_pointer (in/home/fgao/works/test/a. out)
- ==2326 = by 0x8048562: main (in/home/fgao/works/test/a. out)
- ==2326 = Address 0x4021228 is 0 bytes inside a block of size 1 free 'd
- = 2326 = at 0x40057F6: free (vg_replace_malloc.c: 325)
- = 2326 = by 0x8048509: mem_double_free (in/home/fgao/works/test/a. out)
- ==2326 = by 0x804855D: main (in/home/fgao/works/test/a. out)
- = 2326 =
- = 2326 =
- /*
- The file pointer resource leakage is detected here. The following prompt indicates that four file descriptors are still open when they exit.
- The descriptor 0, 1, 2 does not need to be concerned. Through the report, we can find that the file descriptor opened explicitly in the program is not closed.
- */
- = 2326 = file descriptors: 4 open at exit.
- ==2326 = Open file descriptor 3: test.txt
- = 2326 = at 0x68D613: _ open_nocancel (in/lib/libc-2.12.so)
- = 2326 = by 0x61F8EC: _ fopen_internal (in/lib/libc-2.12.so)
- = 2326 = by 0x61F94B: fopen @ GLIBC_2.1 (in/lib/libc-2.12.so)
- = 2326 = by 0x8048496: mem_leak2 (in/home/fgao/works/test/a. out)
- ==2326 = by 0x804854E: main (in/home/fgao/works/test/a. out)
- = 2326 =
- ==2326 = Open file descriptor 2:/dev/pts/4
- = 2326 =
- = 2326 =
- ==2326 = Open file descriptor 1:/dev/pts/4
- = 2326 =
- = 2326 =
- = 2326 = Open file descriptor 0:/dev/pts/4
- = 2326 =
- = 2326 =
- = 2326 =
- /* Summary of heap information: a total of four alloc calls and four free calls. The reason is exactly the same, because one of the above functions is less free, and one function has one more free */
- ==2326 === heap summary:
- = 2326 = in use at exit: 353 bytes in 2 blocks
- = 2326 = total heap usage: 4 allocs, 4 frees, 355 bytes allocated
- = 2326 =
- /* One byte memory leakage detected */
- = 2326 = 1 bytes in 1 blocks are definitely lost in loss record 1 of 2
- = 2326 = at 0x4005BDC: malloc (vg_replace_malloc.c: 195)
- = 2326 = by 0x8048475: mem_leak1 (in/home/fgao/works/test/a. out)
- ==2326 = by 0x8048549: main (in/home/fgao/works/test/a. out)
- = 2326 =
- /* Memory leakage summary */
- = 2326 = leak summary:
- = 2326 = definitely lost: 1 bytes in 1 blocks
- ==2326 = indirectly lost: 0 bytes in 0 blocks
- ==2326 = possibly lost: 0 bytes in 0 blocks
- = 2326 = still reachable: 352 bytes in 1 blocks
- = 2326 = suppressed: 0 bytes in 0 blocks
- = 2326 = Reachable blocks (those to which a pointer was found) are not shown.
- = 2326 = To see them, rerun with: -- leak-check = full -- show-reachable = yes
- = 2326 =
- = 2326 = For counts of detected and suppressed errors, rerun with:-v
- = 2326 = Use -- track-origins = yes to see where uninitialised values come from
- = 2326 = error summary: 5 errors from 5 contexts (suppressed: 12 from 8)
This is just a simple example program. Even without Valgrind, we can easily find problems. But in real projects, when the amount of code reaches 100,000 lines, lines, or even millions of lines. Because the applied memory may not be used in one place, it is inevitable that it will be transmitted. At this time, if you simply check the review code to check the problem, it may be difficult to find the root cause. In this case, Valgrind can easily locate the problem. Of course, Valgrind is not omnipotent. I also encountered a problem that Valgrind could not find. Instead, I found the problem through continuous review code. It is the last stream to discover and solve the problem. The best way is not to introduce memory problems. This can be achieved through a good code style and design.
