Developing with valgrind

Building for valgrind

Compile with the sys_valgrind directory below source. This includes the compiler option

# no not initialize 

Running with valgrind

I 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 -r $1 2> $1.valgrind

This is used for single models.

To run the test suite use in /tsuite. The command line, for running 12-way, will look something like

./ "valgrind --leak-check=full --track-fds=yes /path/to/source/sys_valgrind/cloudy.exe" 12 &

Examining output

The valgrind error output will go to filename.err.

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.'

Note that this simple command will produce spurious error messages FILE DESCRIPTORS: 4 open at exit for fork()-based parallel optimizer runs. This is because the child processes need to keep an additional file descriptor open in order not to interfere with the parent process. These messages can safely be ignored.

Files open when code terminates

The following comments are normal. These are stdin, stdout and stderr. The egrip command excludes these comments.

==13697== FILE DESCRIPTORS: 3 open at exit.
==13697== Open file descriptor 2: /dev/pts/6
==13697==    <inherited from parent>
==13697== Open file descriptor 1: /dev/pts/6
==13697==    <inherited from parent>
==13697== Open file descriptor 0: /dev/pts/6
==13697==    <inherited from parent>

A fourth file is open after fork()-based parallel optimizer runs, as noted above:

==23414== Open file descriptor 4: optimize_phymir.out
==23414==    at 0x35868DAC10: __open_nocancel (in /lib64/
==23414==    by 0x358687259E: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/
==23414==    by 0x3586866AE5: __fopen_internal (in /lib64/
==23414==    by 0x423672: open_data(char const*, char const*, access_scheme) (cpu.cpp:629)
==23414==    by 0x40910C: cdOutput(char const*, char const*) (cddrive.cpp:1524)
==23414==    by 0x4061E3: cdMain(int, char const**) (maincl.cpp:299)
==23414==    by 0x406996: main (maincl.cpp:48)

The egrip command does not exclude this warning. The test suite simulation tsuite / auto / optimize_phymir will have this fourth file. The remaining models will have three open.

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