wiki:DevelopingWithValgrind

Version 8 (modified by peter, 5 years ago) (diff)

fix egrep statement

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 valgrind using run_parallel.pl.

The command line, for running 12-way, will look something like

./run_parallel.pl "valgrind --leak-check=full --track-fds=yes /path/to/source/sys_valgrind/cloudy.exe" 12 &
  • A basic examination of the results can be done with
    egrep 'lost:|ERROR SUMMARY:|FILE DESCRIPTORS:' *.err | egrep -v '0 bytes in 0 blocks|0 errors from 0 contexts| 3 open at exit.'
    

I also keep a shell script on my path, called rungrind, which has these contents:

nice valgrind --leak-check=full  /path/to/cloudy/source/sys_valgrind/cloudy.exe < $1.in >$1.out 2>$1.valgrind

The valgrind error output will go to the filename.valgrind output file.


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