Valgrind for memory leaks
Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools.Complie source code.
$gcc -g hello.c -o a.out
$valgrind --tool=memcheck --leak-check=yes -v --leak-check=full --show-reachable=yes ./a.out==4878== Memcheck, a memory error detector
==4878== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4878== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==4878== Command: ./a.out
==4878==
--4878-- Valgrind options:
--4878-- --tool=memcheck
--4878-- --leak-check=yes
--4878-- -v
--4878-- --leak-check=full
--4878-- --show-reachable=yes
--4878-- Contents of /proc/version:
--4878-- Linux version 4.13.0-36-generic (buildd@lgw01-amd64-033) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)) #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018
--4878--
--4878-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--4878-- Page sizes: currently 4096, max supported 4096
--4878-- Valgrind library directory: /usr/lib/valgrind
--4878-- Reading syms from /home/jpatchs/read_device_name/a.out
--4878-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--4878-- Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--4878-- .. CRC mismatch (computed aa979a42 wanted 9019bbb7)
--4878-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--4878-- .. CRC is valid
--4878-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--4878-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--4878-- .. CRC mismatch (computed eea41ea9 wanted 2009db78)
--4878-- object doesn't have a symbol table
--4878-- object doesn't have a dynamic symbol table
--4878-- Scheduler: using generic scheduler lock implementation.
--4878-- Reading suppressions file: /usr/lib/valgrind/default.supp
==4878== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4878-by-jpatchs-on-???
==4878== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-4878-by-jpatchs-on-???
==4878== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-4878-by-jpatchs-on-???
==4878==
==4878== TO CONTROL THIS PROCESS USING vgdb (which you probably
==4878== don't want to do, unless you know exactly what you're doing,
==4878== or are doing some strange experiment):
==4878== /usr/lib/valgrind/../../bin/vgdb --pid=4878 ...command...
==4878==
==4878== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4878== /path/to/gdb ./a.out
==4878== and then give GDB the following command
==4878== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=4878
==4878== --pid is optional if only one valgrind process is running
==4878==
--4878-- REDIR: 0x401cfd0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--4878-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--4878-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--4878-- .. CRC mismatch (computed 2567ccf6 wanted 49420590)
--4878-- object doesn't have a symbol table
--4878-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--4878-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--4878-- .. CRC mismatch (computed 0e27c9a8 wanted ac585421)
--4878-- object doesn't have a symbol table
==4878== WARNING: new redirection conflicts with existing -- ignoring it
--4878-- old: 0x0401cfd0 (strlen ) R-> (0000.0) 0x3809e181 ???
--4878-- new: 0x0401cfd0 (strlen ) R-> (2007.0) 0x04c31020 strlen
--4878-- REDIR: 0x401b920 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--4878-- REDIR: 0x401bb40 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--4878-- REDIR: 0x401dd30 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--4878-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--4878-- Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--4878-- .. CRC mismatch (computed 7a8ee3e4 wanted a5190ac4)
--4878-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--4878-- .. CRC is valid
--4878-- REDIR: 0x4ec9a00 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ec5280 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ecbcf0 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ec76f0 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ec7a80 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ec914b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--4878-- REDIR: 0x4ec7400 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
==4878== Invalid read of size 1
==4878== at 0x400552: main (in /home/jpatchs/read_device_name/a.out)
==4878== Address 0xf80 is not stack'd, malloc'd or (recently) free'd
==4878==
==4878==
==4878== Process terminating with default action of signal 11 (SIGSEGV)
==4878== Access not within mapped region at address 0xF80
==4878== at 0x400552: main (in /home/jpatchs/read_device_name/a.out)
==4878== If you believe this happened as a result of a stack
==4878== overflow in your program's main thread (unlikely but
==4878== possible), you can try to increase the size of the
==4878== main thread stack using the --main-stacksize= flag.
==4878== The main thread stack size used in this run was 8388608.
--4878-- REDIR: 0x4ebe4f0 (libc.so.6:free) redirected to 0x4c2ed80 (free)
==4878==
==4878== HEAP SUMMARY:
==4878== in use at exit: 0 bytes in 0 blocks
==4878== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4878==
==4878== All heap blocks were freed -- no leaks are possible
==4878==
==4878== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==4878==
==4878== 1 errors in context 1 of 1:
==4878== Invalid read of size 1
==4878== at 0x400552: main (in /home/jpatchs/read_device_name/a.out)
==4878== Address 0xf80 is not stack'd, malloc'd or (recently) free'd
==4878==
==4878== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
You can debug core bump using GDB
No comments:
Post a Comment