On Sat, 17 Apr 2010 11:30:07 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Jed and anyone, > > Is there any way for a running program to determine it is > running under valgrind?
There are probably non-portable ways, but if you include <valgrind/valgrind.h>, then RUNNING_ON_VALGRIND > 0 implies this. I don't know of a way to check only whether valgrind is using a different malloc (i.e. --tool=memcheck), but skipping the sentinels should not be a problem if someone is doing heap/call profiling since presumably they have dealt with memory errors by this point. Note that to use this interface, PETSc would have to be configured with valgrind (so that file can be included). I think it is fairly common for users to install valgrind *after* installing PETSc (because we suggest it) in which case this automatic handling wouldn't be available. On Linux, we can look for the presence of preloaded libraries http://stackoverflow.com/questions/360970/how-detect-whether-running-under-valgrind-in-make-file-or-shell-script Alternatively, we could examine "ps" output, but that sounds like an unreliable mess. I hate bundling with a passion, but RUNNING_ON_VALGRIND expands via VALGRIND_DO_CLIENT_REQUEST which is just another macro (involving a bit of inline assembly, no calls into the valgrind library). The comments in the header (and common sense) suggest that ABI compatibility is crucial in which case it might not be entirely insane to bundle the valgrind.h header so that this macro would always be available. Thoughts? Jed
