Valgrind tools¶

1. --leak-check=full:
   This option enables detailed memory leak checking. Valgrind will show complete information about memory leaks, including the line numbers in the source code where the leaked memory was allocated. It helps you identify and fix memory leaks in your program.
2. --track-origins=yes:
   This option enables the tracking of the origin of uninitialized values. When enabled, Valgrind keeps track of the origins of uninitialized data and reports when the data is used in your program. This helps you find bugs related to using uninitialized variables.
3. --show-leak-kinds=definite:
   This option specifies the types of memory leaks to display. When set to `definite`, Valgrind shows only "definite" memory leaks. Definite leaks are memory blocks that were allocated with functions like `malloc`, `calloc`, or `new`, but were not freed before the program terminated. This option narrows down the leak report to the most relevant information. Other options include:
   • indirect: Shows memory leaks that are due to indirect losses, such as leaked memory in libraries or external code.
   • possible: Shows potential memory leaks that were still accessible at the end of the program but were not explicitly freed. This option is more permissive than definite.
   • reachable: Shows memory still reachable at the end of the program, including memory that was not freed but is still accessible through pointers. It helps identify cases where memory was not explicitly freed but is still reachable in the program.
   • all: Shows all types of memory leaks: definite, indirect, possible, and reachable. This option provides the most comprehensive leak report.
   You can use these options with --show-leak-kinds to control the level of detail in the leak report. For example, to show all types of leaks, you can use --show-leak-kinds=all. If you only want to see definite and possible leaks, you can use --show-leak-kinds=definite,possible, and so on.
4. -s:
   The `-s` option disables Valgrind's interactive prompt. By default, Valgrind starts with an interactive prompt that allows you to control certain aspects of its behavior during runtime. Using the `-s` option suppresses this prompt, making Valgrind run non-interactively, which is useful for scripting and automated testing.

Valgrind is executed in conjunction with the GNU Debugger (GDB), which provides detailed information about memory operations and can help developers find and fix memory-related bugs in their code. GDB is a popular debugger used to analyze and debug programs in various programming languages, including C and C++. GDB allows developers to inspect and manipulate the program's execution, set breakpoints, view variable values, and step through the code to understand its behavior.

By combining Valgrind and GDB, developers can leverage the strengths of both tools for more effective memory analysis and debugging. When you run "Valgrind Memory Analyzer with GDB," you can:

1. detect memory issues Valgrind can track memory operations and identify memory errors, such as reading from uninitialized variables, accessing invalid memory locations, or causing memory leaks
2. debug program execution: GDB allows you to observe the program's behavior, step through the code, set breakpoints, and examine variable values during execution
3. correlate errors with source code: valgrind+GDB can correlate Valgrind's memory-related error messages with the corresponding lines in the source code. This can help pinpoint the exact location of memory issues.

Combining Valgrind and GDB provides developers with a powerful approach to identify, understand, and fix memory-related problems in their C and C++ programs. This integrated analysis allows for a more comprehensive and efficient debugging process, leading to improved program reliability and performance.

Qt Creator then starts up valgrind in debugging mode, allowing you to step through the program code line by line, similar to how debuggers usually operate. Now, the Application Output window displays information just like the one in the terminal window. When quitting, please ensure that you have closed the debugger! Usually, Qt Creator switches from Edit mode to Debug mode automatically when you execute valgrind. However, sometimes Qt Creator may not do so, and to view the Memcheck window, you may need to switch from Edit mode to Debug mode manually.

Valgrind output is not very user-friendly, thus there are extra tools to utilize it better, such as massif-visualizer. Installation:

sudo apt-get install valgrind massif-visualizer

Valgrind must be executed in a tool mode to generate the output in a format the massif tool expects:

valgrind --tool=massif ./EXE

EXE here is the compiled program to be executed. The output will be massif.out.<pid>, where pid is the process id. The output is given as a parameter to the visualizer:

massif-visualizer massif.out.<pid>

provides a memory chart, i.e., heap consumption as a function of time.

Another memory profiler tool that comes with massif is ms_print. For heap usage profiling, it uses ascii art. The command:

ms_print massif.out.<pid>

Callgrind is a Valgrind tool for gathering call-graph and profiling data, enabling developers to analyze program performance and understand function call interactions. Installation:

sudo apt-get install kcachegrind

The procedure is the same as with massif, first, generate output for the tool

valgrind --tool=callgrind EXE

which produces a file callgrind.out.<pid> that is given as a parameter to get visualization and call-graphs.

kcachegrind callgrind.out.<pid>

kcachegrind provides an interactive and powerful way to explore the profiling data generated by Valgrind tools. It is a valuable tool for understanding the performance characteristics of your program, optimizing code, and improving overall efficiency, such as:

1. call graph visualization displays the call graph of the program, showing how functions are called and related to each other. This helps in understanding the program's flow and to identify hotspots.
2. function summary provides a summary of the functions in your program, including the number of calls, the time spent in each function, and the percentage of total execution time each function consumes
3. source code annotation allows you to view your source code with annotated information about each line's execution time and cache usage, making it easier to pinpoint performance bottlenecks
4. call cost analysis shows the cost of function calls, including the number of instructions and cache misses per call, helping you identify expensive function calls
5. memory usage analysis visualizes the profiling data generated by the Massif tool, allowing you to analyze memory usage patterns and identify memory leaks

callgrind_annotate --show-procs=yes callgrind.out.<pid>

By using callgrind_annotate, you can gain insights into how your program utilizes CPU resources, identify areas of code that might be causing performance issues, and make informed decisions about code optimization and efficiency improvements. It is a valuable tool for developers aiming to improve the performance of their programs by leveraging the detailed profiling data generated by Callgrind.