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

[Barry Smith]

On Apr 17, 2010, at 12:33 PM, Jed Brown wrote:

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

    Thanks!

    I have added this support and it seems to turn off -malloc  
appropriately.


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

      I have rigged ./configure to print a nice message on Linux and  
Apple if it does not find valgrind recommending the user install it  
and rerun ./configure. Not a perfect solution, but a start.

      What I really want is for PETSc programs to automatically start  
themselves in valgrind when --with-debugging=1 :-)

     Barry

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