Valgrind Debugging common usage

Valgrind is a tool on Linux (it might work on some other UNIX platforms as well?) that allows validating and debugging memory accesses of applications (in addition to other things like profiling cache accesses and validating some thread locking correctness), which can be very useful for debugging issues in applications written in non-‘safe’ programming languages like C and C++. It can help identify issues like use-after-free, buffer overruns and other similar issues which conventional debuggers (gdb, lldb) might not always catch until is too late (i.e. you just see the segfault, not the original root cause event).

It can also track down memory leaks as well - although other more specialised applications like heaptrack and bytehound can in some cases be better tools to use for just profiling memory usage (as opposed to memory correctness as well), as these other applications just concentrate on that and are in some cases much faster when debugging your application compared to fully running through valgrind. However in some cases I have found both heaptrack and bytehound have produced non-existant (effectively not possible) stacktraces for memory allocations, whereas valgrind doesn’t seem to have this issue.

Additional args:

--track-origins=yes will track the origin of all memory allocations which can be helpful to work out what memory was causing any particular issue.

--leak-check=full will perform full memory leak checking.

--max-threads=2000 or similar is needed if the application being profiled/debugged uses more than the default of 500 threads valgrind can cope with.

--log-file=/tmp/valgrind_run1.txt will tell valgrind to write the output (which can be incredibly verbose) to a file instead of stdout which is often a good idea.