Hi Joesph, I don’t have a solution to your issue, but I’ve found that the valgrind mpi wrapper is necessary to eliminate many of the false positives that the suppressions file can’t.
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mpiwrap.gettingstarted You should LD_PRELOAD the libmpiwrap from your installation. If it’s not there then you can rebuild valgrind with CC=mpicc to have it built. Hope this helps move you towards a solution. Luke > On Nov 14, 2016, at 5:49 AM, Joseph Schuchart <schuch...@hlrs.de> wrote: > > All, > > I am investigating an MPI application using Valgrind and see a load of memory > leaks reported in MPI-related code. Please find the full log attached. Some > observations/questions: > > 1) According to the information available at > https://www.open-mpi.org/faq/?category=debugging#valgrind_clean the > suppression file should help get a clean run of an MPI application despite > several buffers not being free'd by MPI_Finalize. Is this assumption still > valid? If so, maybe the suppression file needs an update as I still see > reports on leaked memory allocated in MPI_Init? > > 2) There seem to be several invalid reads and writes in the > opal_shmem_segment_* functions. Are they significant or can we regard them as > false positives? > > 3) The code example attached allocates memory using MPI_Win_allocate_shared > and frees it using MPI_Win_free. However, Valgrind reports some memory to be > leaking, e.g.: > > ==4020== 16 bytes in 1 blocks are definitely lost in loss record 21 of 234 > ==4020== at 0x4C2DB8F: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4020== by 0xCFDCD47: component_select (osc_sm_component.c:277) > ==4020== by 0x4F39FC3: ompi_osc_base_select (osc_base_init.c:73) > ==4020== by 0x4E945DC: ompi_win_allocate_shared (win.c:272) > ==4020== by 0x4EF6576: PMPI_Win_allocate_shared (pwin_allocate_shared.c:80) > ==4020== by 0x400E96: main (mpi_dynamic_win_free.c:48) > > Can someone please confirm that we the way the shared window memory is free'd > is actually correct? I noticed that the amount of memory that is reported to > be leaking scales with the number of windows that are allocated and free'd. > In our case this happens in a set of unit tests that all allocate their own > shared memory windows and thus the amount of leaked memory piles up quite a > bit. > > I build the code using GCC 5.4.0 using OpenMPI 2.0.1 and ran it on a single > node. How to reproduce: > > $ mpicc -Wall -ggdb mpi_dynamic_win_free.c -o mpi_dynamic_win_free > > $ mpirun -n 2 valgrind --leak-check=full > --suppressions=$HOME/opt/openmpi-2.0.1/share/openmpi/openmpi-valgrind.supp > ./mpi_dynamic_win_free > > Best regards, > Joseph > > -- > Dipl.-Inf. Joseph Schuchart > High Performance Computing Center Stuttgart (HLRS) > Nobelstr. 19 > D-70569 Stuttgart > > Tel.: +49(0)711-68565890 > Fax: +49(0)711-6856832 > E-Mail: schuch...@hlrs.de > > <valgrind_mpi.log><mpi_dynamic_win_free.c>_______________________________________________ > users mailing list > users@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/users _______________________________________________ users mailing list users@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/users
