Scribd
Upload
7 views9 pages

VGDB

The document provides an overview of using Valgrind and GDB for debugging C programs, highlighting their capabilities in detecting memory management issues and allowing for program inspection during execution. It includes examples of Valgrind output indicating memory leaks and instructions for integrating GDB with Valgrind for effective debugging. Additionally, it offers a workflow for utilizing both tools together and resources for further reference.

Uploaded by

boumeuquagakoi-4792
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
7 views9 pages

VGDB

The document provides an overview of using Valgrind and GDB for debugging C programs, highlighting their capabilities in detecting memory management issues and allowing for program inspection during execution. It includes examples of Valgrind output indicating memory leaks and instructions for integrating GDB with Valgrind for effective debugging. Additionally, it offers a workflow for utilizing both tools together and resources for further reference.

Uploaded by

boumeuquagakoi-4792
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Using valgrind

with gdb
Thomas Oulevey
ITLT-8
Tools
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.
It runs on many platforms:
X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, PPC32/Linux, PPC64/Linux,
PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, TILEGX/Linux, X86/Solaris, AMD64/Solaris, ARM/Android (2.3.x and later),
ARM64/Android, X86/Android (4.0 and later), MIPS32/Android, X86/Darwin and AMD64/Darwin (Mac OS X 10.10, with initial support for 10.11)

GDB, the GNU Project debugger, allows you to see what is going on `inside'
another program while it executes -- or what another program was doing at
the moment it crashed.
It supports C, C++, D, Go, Objective-C, Fortran, Java, OpenCL C, Pascal,
assembly, Modula-2, and Ada.
Valgrind Output
$ valgrind --leak-check=full ./t
==9612== HEAP SUMMARY:
==9612== in use at exit: 28 bytes in 2 blocks
==9612== total heap usage: 2 allocs, 0 frees, 28 bytes allocated
==9612==
==9612== 7 bytes in 1 blocks are definitely lost in loss record 1 of 2
==9612== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9612== by 0x4EBB529: strdup (in /usr/lib64/libc-2.17.so)
==9612== by 0x40055E: main (toto.c:7)
==9612==
==9612== 21 bytes in 1 blocks are definitely lost in loss record 2 of 2
==9612== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9612== by 0x4EBB529: strdup (in /usr/lib64/libc-2.17.so)
==9612== by 0x400548: main (toto.c:5)
==9612==
==9612== LEAK SUMMARY:
==9612== definitely lost: 28 bytes in 2 blocks
==9612== indirectly lost: 0 bytes in 0 blocks
==9612== possibly lost: 0 bytes in 0 blocks
==9612== still reachable: 0 bytes in 0 blocks
==9612== suppressed: 0 bytes in 0 blocks
==9612==
GDB
$ gdb ./araignee

Reading symbols from ./araignee...done.


>>> run -t
>>> break myfunc
>>> print myvar

Cheat sheet :

https://www.sthu.org/code/codesnippets/files/gdb_cheatsheet.pdf

http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf
Mixing the tools together
--vgdb=<no|yes|full> [default: yes]
Valgrind will provide "gdbserver" functionality
when --vgdb=yes or --vgdb=full is specified.
This allows an external GNU GDB debugger to control
and debug your program when it runs on

--vgdb-error=<number> [default: 999999999]


Tools that report errors will wait for "number" errors
to be reported before freezing the program
and waiting for you to connect with GDB.
buggy C code : araignee.c
1 #include <stdio.h>
2 #include <stdlib.h>
3
4 int main(void)
Memory leak ; 5 {
6 char *p = malloc(10);
Variable malloced but not freed (10 bytes) 7 *p = 'a';
8 int i =42;
$ gcc -g -O1 -o araignee araignee.c 9 char c = *p;
10
$ valgrind --leak-check=full \ 11 printf("\n [%i][%c]\n", i, c);
--vgdb=yes --vgdb-error=0 ./araignee 12
13 return 0;
==13245== TO DEBUG THIS PROCESS USING GDB: start GDB like this 14 }
==13245== /path/to/gdb ./araignee
==13245== and then give GDB the following command
==13245== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=13245
==13245== --pid is optional if only one valgrind process is running $ gcc -c -Q -O1 --help=optimizers
Workflow 1 . Run your program under GDB and
$ gdb ./araignee Valgrind
Reading symbols from ./araignee...done.
>>> target remote | vgdb 2 . Put a break at where you think the
Remote debugging using | vgdb memory is lost
relaying data between gdb and process 13850
>>> break 7
break 7
>>> break 14 break main
Breakpoint 1 at 0x400596: file araignee.c, line 7.
Undefined command: "". Try "help". 3. Continue there
>>> continue continue
>>> monitor leak_check
==13850== All heap blocks were freed -- no leaks are possible
>>> continue
4. Check for memory leak
>>> monitor leak_check monitor leak_check
==13850== LEAK SUMMARY:
==13850== definitely lost: 10 bytes in 1 blocks 5. reiterate until you find the leak
==13850== indirectly lost: 0 bytes in 0 blocks next / step / continue / print
==13850== possibly lost: 0 bytes in 0 blocks monitor leak_check
==13850== still reachable: 0 bytes in 0 blocks
==13850== suppressed: 0 bytes in 0 blocks
>>> break araignee.c:8 if i == 42
Cool gdb tuning

gdb-dashboard

https://github.com/cyrus-and/gdb-dashboard
Thank you !

SSSD bug : https://fedorahosted.org/sssd/ticket/2803

Thanks, Sebastien Ponce for the debug session

You might also like