[petsc-dev] MPICH from --download-mpich reports inconsistent allocs/frees with valgrind

[Balay, Satish]

Hm - I don't think we were monitoring the leaks via valgrind that closely.

Looking at my old mpich install - I don't see a problem - so likely
its an issue with newer versions of mpich.

Satish

-------
balay at sb /home/balay/tmp
$ mpichversion 
MPICH Version:    	3.3
MPICH Release date:	Wed Nov 21 11:32:40 CST 2018
MPICH Device:    	ch3:sock
MPICH configure: 	--prefix=/home/balay/soft/mpich-3.3 MAKE=/usr/bin/gmake --libdir=/home/balay/soft/mpich-3.3/lib CC=gcc CFLAGS=-fPIC -g -O AR=/usr/bin/ar ARFLAGS=cr CXX=g++ CXXFLAGS=-g -O -fPIC F77=gfortran FFLAGS=-fPIC -g -O FC=gfortran FCFLAGS=-fPIC -g -O --enable-shared --with-device=ch3:sock --with-pm=hydra --enable-fast=no --enable-error-messages=all --enable-g=meminit
MPICH CC: 	gcc -fPIC -g -O   -O0
MPICH CXX: 	g++ -g -O -fPIC  -O0
MPICH F77: 	gfortran -fPIC -g -O  -O0
MPICH FC: 	gfortran -fPIC -g -O  -O0
MPICH Custom Information: 	
balay at sb /home/balay/tmp
$ printf "#include<mpi.h>\nint main(int a,char**b){MPI_Init(&a,&b);MPI_Finalize();}" > t.c && mpicc t.c && valgrind ./a.out
==9024== Memcheck, a memory error detector
==9024== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9024== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==9024== Command: ./a.out
==9024== 
==9024== 
==9024== HEAP SUMMARY:
==9024==     in use at exit: 0 bytes in 0 blocks
==9024==   total heap usage: 1,886 allocs, 1,886 frees, 4,884,751 bytes allocated
==9024== 
==9024== All heap blocks were freed -- no leaks are possible
==9024== 
==9024== For lists of detected and suppressed errors, rerun with: -s
==9024== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
balay at sb /home/balay/tmp



On Mon, 22 Jul 2019, Patrick Sanan via petsc-dev wrote:

> It was pointed out to me that valgrind memcheck reports inconsistent heap
> usage information when running PETSc examples. All blocks are reported
> freed, yet the number of allocations and frees are different. My guess as
> to what's going on is that this is an MPICH issue, as I can reproduce the
> behavior with a minimal MPI program.
> 
> >From the PETSc perspective, is this a known issue?  I'm wondering if this
> inconsistency was always there, whether it's worth looking into more, etc.
> 
> Here's a 1-liner to reproduce, using a PETSc master build with
> --download-mpich (though note that this doesn't use anything from PETSc
> except the MPICH it builds for you).
> 
>      printf "#include<mpi.h>\nint main(int a,char
> **b){MPI_Init(&a,&b);MPI_Finalize();}" > t.c &&
> $PETSC_DIR/$PETSC_ARCH/bin/mpicc t.c && valgrind ./a.out
> 
> ==14242== Memcheck, a memory error detector
> ==14242== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==14242== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==14242== Command: ./a.out
> ==14242==
> ==14242==
> ==14242== HEAP SUMMARY:
> ==14242==     in use at exit: 0 bytes in 0 blocks
> ==14242==   total heap usage: *1,979 allocs, 1,974 frees*, 4,720,483 bytes
> allocated
> ==14242==
> ==14242== All heap blocks were freed -- no leaks are possible
> ==14242==
> ==14242== For counts of detected and suppressed errors, rerun with: -v
> ==14242== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>