[petsc-dev] Tip while using valgrind

[Jed Brown]

"Smith, Barry F. via petsc-dev" <petsc-dev at mcs.anl.gov> writes:

>   When using valgrind it is important to understand that it does not immediately make a report when it finds an uninitialized memory, it only makes a report when an uninitialized memory would cause a change in the program flow (like in an if statement). This is why sometimes it seems to report an uninitialized variable that doesn't make sense. It could be that the value at the location came from an earlier uninitialized location and that is why valgrind is reporting it, not because the reported location was uninitialized.  Using the valgrind option --track-origins=yes is very useful since it will always point back to the area of memory that had the uninitialized value.

Yes, I sometimes wish --track-origins was the default, though it does
slow Valgrind down even more.

>  I'm sending this out because twice recently I've struggled with cases where the initialized location "traveled" a long way before valgrind reported it and my confusion as to how valgrind worked kept making me leap to the wrong conclusions.

We can also use Valgrind client checks to assert that memory is defined at various stages.

  VALGRIND_CHECK_MEM_IS_DEFINED

http://valgrind.org/docs/manual/mc-manual.html