[petsc-users] Discrepancy between valgrind and -malloc_dump output

[Junchao Zhang]

You might use OpenMPI. From my experience, OpenMPI is not valgrind clear.
As you can see the leaks happened in MPI_Init_thread. Try use MPICH, for
example, use the --download-mpich option.  petsc's -malloc_debug only
traces memory allocated by petsc, not OpenMPI.

--Junchao Zhang


On Mon, Mar 9, 2020 at 2:47 PM Zane Charles Jakobs <Zane.Jakobs at colorado.edu>
wrote:

> Hi PETSc devs,
>
> I have a C++ program written with PETSc (code available at
> https://github.com/DiffeoInvariant/NLTS/blob/master/examples/mutual_opt.cpp),
> and if I run it with -malloc_debug and -malloc_dump enabled, PETSc says no
> memory is left unfreed at exit. However, running with valgrind
> --leak-check=full --show-leak-kinds=all gives me this leak summary:
>
> LEAK SUMMARY:
> ==15364==    definitely lost: 0 bytes in 0 blocks
> ==15364==    indirectly lost: 0 bytes in 0 blocks
> ==15364==      possibly lost: 0 bytes in 0 blocks
> ==15364==    still reachable: 610,904 bytes in 8,246 blocks
> ==15364==         suppressed: 0 bytes in 0 blocks
>
> The information from --show-leak-kinds=all gives several blocks of the
> form (this is the last block printed; I've attached the full output from
> valgrind to this email)
>
> ==15364== 329,080 bytes in 3 blocks are still reachable in loss record 7
> of 7
> ==15364==    at 0x483CFAF: realloc (in
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15364==    by 0x7BDE1A7: ??? (in
> /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1)
> ==15364==    by 0x7BDE41C: ??? (in
> /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1)
> ==15364==    by 0x7BDE579: pci_device_get_device_name (in
> /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1)
> ==15364==    by 0x759CFC4: hwloc_look_pci (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libmpi.so.12.1.8)
> ==15364==    by 0x7571D0B: hwloc_discover (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libmpi.so.12.1.8)
> ==15364==    by 0x7571637: hwloc_topology_load (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libmpi.so.12.1.8)
> ==15364==    by 0x736780A: MPIR_Init_thread (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libmpi.so.12.1.8)
> ==15364==    by 0x7367435: PMPI_Init_thread (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libmpi.so.12.1.8)
> ==15364==    by 0x491CABA: PetscInitialize (in
> /usr/local/petsc/arch-linux-cxx-debug/lib/libpetsc.so.3.012.4)
> ==15364==    by 0x724AB0E: nlts::io::Initialize(int*, char***, char
> const*, char const*) (io.cpp:126)
> ==15364==    by 0x4023CB: main (mutual_opt.cpp:30)
>
> The function nlts::io::Initialize that's referenced at the bottom is simply
>
> PetscErrorCode nlts::io::Initialize(int *argc, char ***argv,
> const char file[],
> const char help[])
> {
> PetscFunctionBeginUser;
> auto ierr = PetscInitialize(argc, argv, file, help);CHKERRQ(ierr);
> PetscFunctionReturn(ierr);
> }
>
> Is valgrind actually detecting unfreed memory here, or is this something I
> don't need to worry about?
>
> Thanks!
>
> -Zane Jakobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200309/072a60c4/attachment.html>