"Smith, Barry F. via petsc-dev" <petsc-dev@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
