Thanks a lot, Matt and Barry. Indeed, I found the original leak that will lead to something related to DMGetWorkArray. ==15547== 50,000 bytes in 1 blocks are definitely lost in loss record 2,786 of 2,791 ==15547== at 0x4C37135: malloc (vg_replace_malloc.c:381) ==15547== by 0x9BE4E43: MPL_malloc (mpl_trmem.h:373) ==15547== by 0x9BE6B3B: PMIU_cmd_add_int (pmi_wire.c:538) ==15547== by 0x9BEB7C6: PMIU_msg_set_query_abort (pmi_msg.c:322) ==15547== by 0x9BE16F0: PMI_Abort (pmi_v1.c:327) ==15547== by 0x9A8E3E7: MPIR_pmi_abort (mpir_pmi.c:243) ==15547== by 0x9B20BC7: MPID_Abort (mpid_abort.c:67) ==15547== by 0x9A22823: MPIR_Abort_impl (init_impl.c:270) ==15547== by 0x97FFF02: internal_Abort (abort.c:65) ==15547== by 0x98000C3: PMPI_Abort (abort.c:112) ==15547== by 0x58FE116: PetscError (err.c:403) ==15547== by 0x410CA3: main (ex1.c:764) //Call DMDestroy(); On Fri, Jun 9, 2023 at 12:38 PM Barry Smith <[email protected]> wrote:
This are MPI objects PETSc creates in PetscInitialize(), for successful runs they should all be removed in PETSc finalize, hence they should not appear as valgrind links.
Are you sure PetscFinalize() is called and completes?
We'll need the exact PETSc version you are using to know exactly which MPI object is not being destroyed.
Barry
On Jun 9, 2023, at 12:01 PM, neil liu <[email protected]> wrote:
Dear Petsc developers,
I am using valgrind to check the memory leak. It shows, <image.png> Finally, I found that DMPlexrestoretrasitiveclosure can resolve this memory leak.
My question is from the above screen shot, it seems the leak is related to MPI. How can I relate that reminder to DMPlexrestoretrasitiveclosure ?
Thanks,
Xiaodong