Valgrind – dynamic code analysis tool – part I – basic trial and hints

We are recently trying to find a tool providing the ability for concurrency issue detection. For this topic, generally, I believe in 3 steps: 1. CPR (capacity, performance, redundancy) testing, 2. Static code analysis, 3. Dynamic code analysis. CPR testing is the same thing for each product before delivery; Coverity/Klocwork (not free!) would be the ones for SCA; Insure++/Bulleye could be the ones standing for DCA. However, for DCA requesting concurrency specific and free, Valgrind would be our first choice. From this post, we will try to go thru some details about Valgrind and then focus on some key detection like concurrency. May it help.

# Download source code
http://valgrind.org/downloads/current.html

# Unzip the pkg
bunzip valgrind-3.7.0.tar.bz2
tar -xvf valgrind-3.7.0.tar

# Build, install and test
./configure
make
make install
valgrind ls -l
[root@localhost valgrindTest]# ldd /usr/local/bin/valgrind
        linux-gate.so.1 =>  (0x00e3b000)
        libc.so.6 => /lib/libc.so.6 (0x00606000)
        /lib/ld-linux.so.2 (0x005e7000)
[root@localhost valgrindTest]#

# Or rpm installation for Linux
http://rpmfind.net/linux/rpm2html/search.php?query=valgrind

# GUIs
http://valgrind.org/downloads/guis.html
# Check and find the the useful tools
http://valgrind.org/docs/manual/manual-intro.html
1. Memcheck is a memory error detector. It helps you make your programs, particularly those written in C and C++, more correct.
2. Cachegrind is a cache and branch-prediction profiler. It helps you make your programs run faster.
3. Callgrind is a call-graph generating cache profiler. It has some overlap with Cachegrind, but also gathers some information that Cachegrind does not.
4. Helgrind is a thread error detector. It helps you make your multi-threaded programs more correct.
5. DRD is also a thread error detector. It is similar to Helgrind but uses different analysis techniques and so may find different problems.
6. Massif is a heap profiler. It helps you make your programs use less memory.
7. DHAT is a different kind of heap profiler. It helps you understand issues of block lifetimes, block utilisation, and layout inefficiencies.
8. SGcheck is an experimental tool that can detect overruns of stack and global arrays. Its functionality is complementary to that of Memcheck: SGcheck fi
nds problems that Memcheck can't, and vice versa..
9. BBV is an experimental SimPoint basic block vector generator. It is useful to people doing computer architecture research and development.
10. Lackey is an example tool that illustrates some instrumentation basics.
11. Nulgrind is the minimal Valgrind tool that does no analysis or instrumentation, and is only useful for testing purposes.
# Quick start using Memcheck
http://valgrind.org/docs/manual/quick-start.html
[root@localhost valgrindTest]# cat memcheckTry.c
/* Code from Valgrind Manual */
#include <stdlib.h>

 void f(void)
 {
 int* x = malloc(10 * sizeof(int));
 x[10] = 0; // problem 1: heap block overrun
 } // problem 2: memory leak -- x not freed

 int main(void)
 {
 f();
 return 0;
}
[root@localhost valgrindTest]#
gcc -Wall -g -o memcheckTry memcheckTry.c
[root@localhost valgrindTest]# valgrind --leak-check=yes ./memcheckTry
==16907== Memcheck, a memory error detector
==16907== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==16907== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==16907== Command: ./memcheckTry
==16907==
==16907== Invalid write of size 4
==16907==    at 0x80483BF: f (memcheckTry.c:6)
==16907==    by 0x80483DC: main (memcheckTry.c:11)
==16907==  Address 0x4017050 is 0 bytes after a block of size 40 alloc'd
==16907==    at 0x400705E: malloc (vg_replace_malloc.c:263)
==16907==    by 0x80483B5: f (memcheckTry.c:5)
==16907==    by 0x80483DC: main (memcheckTry.c:11)
==16907==
==16907==
==16907== HEAP SUMMARY:
==16907==     in use at exit: 40 bytes in 1 blocks
==16907==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==16907==
==16907== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==16907==    at 0x400705E: malloc (vg_replace_malloc.c:263)
==16907==    by 0x80483B5: f (memcheckTry.c:5)
==16907==    by 0x80483DC: main (memcheckTry.c:11)
==16907==
==16907== LEAK SUMMARY:
==16907==    definitely lost: 40 bytes in 1 blocks
==16907==    indirectly lost: 0 bytes in 0 blocks
==16907==      possibly lost: 0 bytes in 0 blocks
==16907==    still reachable: 0 bytes in 0 blocks
==16907==         suppressed: 0 bytes in 0 blocks
==16907==
==16907== For counts of detected and suppressed errors, rerun with: -v
==16907== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 8)
[root@localhost valgrindTest]#
# General compiling options
-g
-fno-inline (C++)
-Wall
NOTE: Turn off '-Ox' or only go with '-O'

# Logging options
--log-file=<filename>

# XML report options (for GUI's consuming)
--xml=yes --xml-file=<filename>

# Memory leak detection
--tool=memcheck (default)

About daveti

Interested in kernel hacking, compilers, machine learning and guitars.
This entry was posted in Static Code Analysis and tagged , , , . Bookmark the permalink.

One Response to Valgrind – dynamic code analysis tool – part I – basic trial and hints

  1. daveti says:

    Another very good post focusing on concurrency issue detection especially for Java code:
    http://sqrg.science.uoit.ca/blog/?p=32

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s