<div dir="ltr">Quick question : To drop a print statement at the required location, I need to modify the source code, build petsc from source and compile with this new version of petsc, right or is there an easier way? (Just to confirm before putting in the effort)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 8:42 PM Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  Dang, I  ranted too soon.<br>
<br>
  I built mpich  using spack (master branch) and a very old Gnu C compiler and it produced valgrind clean code. Spack definitely is not passing the --enable-g=meminit to MPICH ./configure so this version of MPICH valgrind must be clean by default? MPICH's ./configure has<br>
<br>
meminit  - Preinitialize memory associated structures and unions to<br>
                   eliminate access warnings from programs like valgrind<br>
<br>
The default for enable-g is most and<br>
<br>
most|yes)<br>
        perform_memtracing=yes<br>
        enable_append_g=yes<br>
        perform_meminit=yes<br>
        perform_dbgmutex=yes<br>
        perform_mutexnesting=yes<br>
        perform_handlealloc=yes<br>
        perform_handle=yes<br>
<br>
So it appears that at least some releases of MPICH are suppose to be valgrind clean by default ;).<br>
<br>
Looking back at Sajid's valgrind output more carefully<br>
<br>
Conditional jump or move depends on uninitialised value(s)<br>
==15359==    at 0x1331069A: __intel_sse4_strncmp (in /opt/intel/compilers_and_libraries_2019.1.144/linux/compiler/lib/intel64_lin/libintlc.so.5)<br>
<br>
is the only valgrind error. Which I remember seeing from using Intel compilers for a long time, nothing to do with MPICH<br>
<br>
Thus I conclude that Sajid's code is actually valgrind clean; and I withdraw my rant about MPICH/spack<br>
<br>
Barry<br>
<br>
<br>
<br>
> On Apr 16, 2019, at 5:13 PM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
>  So valgrind is printing all kinds of juicy information about uninitialized values but it is all worthless because MPICH was not built by spack to be valgrind clean. We can't know if any of the problems valgrind flags are real. MPICH needs to be configured with the option --enable-g=meminit to be valgrind clean. PETSc's --download-mpich always installs a valgrind clean MPI.<br>
><br>
> It is unfortunate Spack doesn't provide a variant of MPICH that is valgrind clean; actually it should default to valgrind clean MPICH.<br>
><br>
>  Barry<br>
><br>
><br>
><br>
><br>
>> On Apr 16, 2019, at 2:43 PM, Sajid Ali via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
>><br>
>> So, I tried running the debug version with valgrind to see if I can find the chunk size that's being set but I don't see it. Is there a better way to do it ?<br>
>><br>
>> `$ mpirun -np 32 valgrind ./ex_ms -prop_steps 1 -info &> out`. [The out file is attached.]<br>
>> <out><br>
><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-size:12.8px">Sajid Ali<br></div><div style="font-size:12.8px">Applied Physics<br></div><div style="font-size:12.8px">Northwestern University</div></div></div>