2.5 Verifying Applications

2.5.1 Using Gcov to Analyze Code Coverage
2.5.2 Using Valgrind to Detect Memory Access Errors and Leaks

Functional testing is the most critical phase in the migration process. Many of the system calls and features on both platforms look similar, but there are subtle behavioral differences that can be uncovered only during testing. Even if the code compiles on the new platform, it might behave significantly different during actual test runs. Hence, it is very important to ensure that the applications are thoroughly tested on the target platform.

Oracle Solaris Studio provides the Uncover and Tcov tools to track code coverage during testing, and the Discover tool to unearth difficult to detect code issues, such as memory access errrors and leaks. Alternatively, you can use open-source tools such as Gcov and Valgrind.

For information about using Uncover, Tcov, and Discover, see the Oracle Solaris Studio Documentation.

2.5.1 Using Gcov to Analyze Code Coverage

Gcov is an open-source code-coverage tool.

To use Gcov, perform the following steps:

  1. Compile the code with the -fprofile-arcs and -ftest-coverage flags, for example:

    $ gcc -fprofile-arcs -ftest-coverage test.c

    The -ftest-coverage flag causes gcc to add instrumentation codes to the binary.

  2. Run the instrumented binary and perform functional testing.

    Running the binary generates profile output. For each source file that you compiled with -fprofile-arcs, a .gcda profile output file is created in the object file directory.

  3. Generate a report file based on the data that is stored in the profile output files:

    $ gcov test.c
    56.0% of 110 source lines executed in file test.c
    Creating test.c.gcov.

For more information about using gcov, see the gcov(1) manual page.

2.5.2 Using Valgrind to Detect Memory Access Errors and Leaks

Valgrind is a open-source memory access error and leak detection tool.

To use Valgrind, perform the following steps:

  1. Compile the code with the -g flag, for example:

    $ gcc -g -O1 test.c

    An optimization level of 1 is generally faster than level 0, although it can cause incorrect line numbers to be reported.

    An optimization level higher than 1 can cause spurious uninitialised-value errors to be reported.

  2. Use the valgrind as a wrapper for running the binary and perform stress testing:

    $ valgrind --leak-check=yes --log-file=valgrind.rpt a.out

    Memory access checking is enabled by default. The --leak-check option runs the memory leak detector when the binary exits. If you specify its value as summary, it reports how many leaks occurred. A value of full or yes displays the details of each individual leak.

For more information about using Valgrind, see the valgrind(1) manual page and the Valgrind Documentation at http://www.valgrind.org/docs/manual/index.html.