|Version 4 (modified by gary, 3 years ago)|
developing with valgrind
building, running, and examining output
- Compile with the sys_valgrind directory below source. This includes the compiler option
# no not initialize CXXFLAGS += -DNOINIT
- Run using the valgrind instructions in run_parallel.pl.
The command line, for running 12-way, will look something like
./run_parallel.pl "valgrind --leak-check=full ../../source/sys_valgrind/cloudy.exe" 12
- Examine results with
egrep 'lost:|ERROR SUMMARY:' *.err | egrep -v '0 bytes in 0 blocks|0 errors from 0 contexts'
valgrind on a Mac
must include this option
--dsymutil=no|yes [no]This option is only relevant when running Valgrind on Mac OS X.
Mac OS X uses a deferred debug information (debuginfo) linking scheme. When object files containing debuginfo are linked into a .dylib or an executable, the debuginfo is not copied into the final file. Instead, the debuginfo must be linked manually by running dsymutil, a system-provided utility, on the executable or .dylib. The resulting combined debuginfo is placed in a directory alongside the executable or .dylib, but with the extension .dSYM.
With --dsymutil=no, Valgrind will detect cases where the .dSYM directory is either missing, or is present but does not appear to match the associated executable or .dylib, most likely because it is out of date. In these cases, Valgrind will print a warning message but take no further action.
With --dsymutil=yes, Valgrind will, in such cases, automatically run dsymutil as necessary to bring the debuginfo up to date. For all practical purposes, if you always use --dsymutil=yes, then there is never any need to run dsymutil manually or as part of your applications's build system, since Valgrind will run it as necessary. Valgrind will not attempt to run dsymutil on any executable or library in /usr/, /bin/, /sbin/, /opt/, /sw/,/System/, /Library/ or /Applications/ since dsymutil will always fail in such situations. It fails both because the debuginfo for such pre-installed system components is not available anywhere, and also because it would require write privileges in those directories.
Be careful when using --dsymutil=yes, since it will cause pre-existing .dSYM directories to be silently deleted and re-created. Also note the dsymutil is quite slow, sometimes excessively so.
Return to DeveloperPages
Return to main wiki page
Return to nublado.org