Memory debugging-valgrind tool detects array access errors and memory leaks, valgrind leaks

Source: Internet
Author: User
Tags valgrind

Memory debugging-valgrind tool detects array access errors and memory leaks, valgrind leaks

The following C program allocates 1024 bytes of memory, reads data from areas outside the allocated memory, writes data after the end of the allocated memory, and finally makes the memory area inaccessible.

#include <stdio.h>#include <stdlib.h>int main(){    char *ptr = (char *)malloc( 1024 );    char ch;    //Uninitialized read    ch = ptr[1024];    //Write beyond the block    ptr[1024] = 0;    //Orphan the block    ptr = 0;    return 0;}

The following is the result of the valgrind tool: All the memory management errors are detected.

[zhang@localhost document]$ valgrind --leak-check=yes -v ./checker==19044== Memcheck, a memory error detector==19044== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.==19044== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info==19044== Command: ./checker==19044== --19044-- Valgrind options:--19044--    --leak-check=yes--19044--    -v--19044-- Contents of /proc/version:--19044--   Linux version 2.6.32-504.3.3.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Dec 17 01:55:02 UTC 2014--19044-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx--19044-- Page sizes: currently 4096, max supported 4096--19044-- Valgrind library directory: /usr/local/lib/valgrind--19044-- Reading syms from /home/zhang/document/checker--19044-- Reading syms from /usr/local/lib/valgrind/memcheck-amd64-linux--19044--    object doesn't have a dynamic symbol table--19044-- Reading syms from /lib64/ld-2.12.so--19044-- Scheduler: using generic scheduler lock implementation.--19044-- Reading suppressions file: /usr/local/lib/valgrind/default.supp==19044== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-19044-by-zhang-on-localhost.localdomain==19044== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-19044-by-zhang-on-localhost.localdomain==19044== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-19044-by-zhang-on-localhost.localdomain==19044== ==19044== TO CONTROL THIS PROCESS USING vgdb (which you probably==19044== don't want to do, unless you know exactly what you're doing,==19044== or are doing some strange experiment):==19044==   /usr/local/lib/valgrind/../../bin/vgdb --pid=19044 ...command...==19044== ==19044== TO DEBUG THIS PROCESS USING GDB: start GDB like this==19044==   /path/to/gdb ./checker==19044== and then give GDB the following command==19044==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=19044==19044== --pid is optional if only one valgrind process is running==19044== --19044-- REDIR: 0x3283e17610 (ld-linux-x86-64.so.2:strlen) redirected to 0x38051201 (vgPlain_amd64_linux_REDIR_FOR_strlen)--19044-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-amd64-linux.so--19044-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so==19044== WARNING: new redirection conflicts with existing -- ignoring it--19044--     old: 0x3283e17610 (strlen              ) R-> (0000.0) 0x38051201 vgPlain_amd64_linux_REDIR_FOR_strlen--19044--     new: 0x3283e17610 (strlen              ) R-> (2007.0) 0x04a08960 strlen--19044-- REDIR: 0x3283e17480 (ld-linux-x86-64.so.2:index) redirected to 0x4a08540 (index)--19044-- REDIR: 0x3283e17500 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4a09320 (strcmp)--19044-- REDIR: 0x3283e183f0 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4a0bd80 (mempcpy)--19044-- Reading syms from /lib64/libc-2.12.so--19044-- REDIR: 0x3284284cd0 (libc.so.6:strcasecmp) redirected to 0x480155c (_vgnU_ifunc_wrapper)--19044-- REDIR: 0x3284286f90 (libc.so.6:strncasecmp) redirected to 0x480155c (_vgnU_ifunc_wrapper)--19044-- REDIR: 0x3284282c40 (libc.so.6:__GI_strrchr) redirected to 0x4a082d0 (__GI_strrchr)--19044-- REDIR: 0x328427a640 (libc.so.6:malloc) redirected to 0x4a07183 (malloc)==19044== Invalid read of size 1==19044==    at 0x4004E4: main (in /home/zhang/document/checker)==19044==  Address 0x4c2b440 is 0 bytes after a block of size 1,024 alloc'd==19044==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)==19044==    by 0x4004D5: main (in /home/zhang/document/checker)==19044== ==19044== Invalid write of size 1==19044==    at 0x4004F4: main (in /home/zhang/document/checker)==19044==  Address 0x4c2b440 is 0 bytes after a block of size 1,024 alloc'd==19044==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)==19044==    by 0x4004D5: main (in /home/zhang/document/checker)==19044== --19044-- REDIR: 0x328427b520 (libc.so.6:free) redirected to 0x4a06b5d (free)==19044== ==19044== HEAP SUMMARY:==19044==     in use at exit: 1,024 bytes in 1 blocks==19044==   total heap usage: 1 allocs, 0 frees, 1,024 bytes allocated==19044== ==19044== Searching for pointers to 1 not-freed blocks==19044== Checked 64,184 bytes==19044== ==19044== 1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1==19044==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)==19044==    by 0x4004D5: main (in /home/zhang/document/checker)==19044== ==19044== LEAK SUMMARY:==19044==    definitely lost: 1,024 bytes in 1 blocks==19044==    indirectly lost: 0 bytes in 0 blocks==19044==      possibly lost: 0 bytes in 0 blocks==19044==    still reachable: 0 bytes in 0 blocks==19044==         suppressed: 0 bytes in 0 blocks==19044== ==19044== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4)==19044== ==19044== 1 errors in context 1 of 3:==19044== Invalid write of size 1==19044==    at 0x4004F4: main (in /home/zhang/document/checker)==19044==  Address 0x4c2b440 is 0 bytes after a block of size 1,024 alloc'd==19044==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)==19044==    by 0x4004D5: main (in /home/zhang/document/checker)==19044== ==19044== ==19044== 1 errors in context 2 of 3:==19044== Invalid read of size 1==19044==    at 0x4004E4: main (in /home/zhang/document/checker)==19044==  Address 0x4c2b440 is 0 bytes after a block of size 1,024 alloc'd==19044==    at 0x4A0720A: malloc (vg_replace_malloc.c:296)==19044==    by 0x4004D5: main (in /home/zhang/document/checker)==19044== --19044-- --19044-- used_suppression:      4 U1004-ARM-_dl_relocate_object /usr/local/lib/valgrind/default.supp:1401==19044== ==19044== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4)

Where the valgrind tool can find it on the http://valgrind.org.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.