[petsc-dev] [petsc-users] glibc detected

[Jed Brown]

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