OK so I just ran the example under valgrind, and if I use two VecViews, it complains about following leak:
==66838== 24,802 (544 direct, 24,258 indirect) bytes in 1 blocks are definitely lost in loss record 924 of 926 ==66838== at 0x100009EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) ==66838== by 0x10005E638: PetscMallocAlign (in /usr/local/Cellar/petsc/3.7.2/real/lib/libpetsc.3.7.2.dylib) ==66838== by 0x100405F00: DMCreate_DA (in /usr/local/Cellar/petsc/3.7.2/real/lib/libpetsc.3.7.2.dylib) ==66838== by 0x1003CFFA4: DMSetType (in /usr/local/Cellar/petsc/3.7.2/real/lib/libpetsc.3.7.2.dylib) ==66838== by 0x100405B7F: DMDACreate (in /usr/local/Cellar/petsc/3.7.2/real/lib/libpetsc.3.7.2.dylib) ==66838== by 0x1003F825F: DMDACreate2d (in /usr/local/Cellar/petsc/3.7.2/real/lib/libpetsc.3.7.2.dylib) ==66838== by 0x100001D89: main (main_test.cpp:7) By I am destroying the dm ... also I dont get this when using a single VecView. As a bonus info, PETSC_VIEWER_STDOUT_WORLD is just fine, so this looks like it is definitely vtk related. On Wed, Aug 3, 2016 at 2:05 PM, Mohammad Mirzadeh <[email protected]> wrote: > On Wed, Aug 3, 2016 at 10:59 AM, Matthew Knepley <[email protected]> > wrote: > >> On Tue, Aug 2, 2016 at 12:40 PM, Mohammad Mirzadeh <[email protected]> >> wrote: >> >>> I often use the memory usage information in log_view as a way to check >>> on memory leaks and so far it has worked perfect. However, I had long >>> noticed a false-positive report in memory leak for Viewers, i.e. >>> destruction count is always one less than creation. >>> >> >> Yes, I believe that is the Viewer being used to print this information. >> > > That makes sense. > >> >> >>> Today, I noticed what seems to be a second one. If you use VecView to >>> write the same DA to vtk, i.e. call VecView(A, vtk); twice, it also report >>> a memory leak for vectors, vecscatters, dm, etc. I am calling this a >>> false-positive since the code is valgrind-clean. >>> >>> Is this known/expected? >>> >> >> The VTK viewers have to hold everything they output until they are >> destroyed since the format does not allow immediate writing. >> I think the VTK viewer is not destroyed at the time of this output. Can >> you make a small example that does this? >> > > Here's a small example that illustrates the issues > > #include <petsc.h> > > > int main(int argc, char *argv[]) { > > PetscInitialize(&argc, &argv, NULL, NULL); > > > DM dm; > > DMDACreate2d(PETSC_COMM_WORLD, DM_BOUNDARY_NONE, DM_BOUNDARY_NONE, > DMDA_STENCIL_BOX, > > -10, -10, PETSC_DECIDE, PETSC_DECIDE, 1, 1, NULL, NULL, > > &dm); > > // DMDASetUniformCoordinates(dm, -1, 1, -1, 1, 0, 0); > > > Vec sol; > > DMCreateGlobalVector(dm, &sol); > > VecSet(sol, 0); > > > PetscViewer vtk; > > PetscViewerVTKOpen(PETSC_COMM_WORLD, "test.vts", FILE_MODE_WRITE, &vtk); > > VecView(sol, vtk); > > // VecView(sol, vtk); > > PetscViewerDestroy(&vtk); > > > DMDestroy(&dm); > > VecDestroy(&sol); > > > PetscFinalize(); > > return 0; > > } > > > If you uncomment the second VecView you get reports for leaks in > VecScatter and dm. If you also uncomment the DMDASetUniformCoordinates, and > use both VecViews, you also get a leak report for Vecs ... its quite > bizarre ... > > >> I have switched to HDF5 and XDMF due to the limitations of VTK format. >> >> > I had used XDMF + raw binary in the past and was satisfied with the > result. Do you write a single XDMF as a "post-processing" step when the > simulation is finished? If I remember correctly preview could not open xmf > files as time-series. > >> Thanks, >> >> Matt >> >> >>> Here's the relevant bit from log_view: >>> >>> --- Event Stage 0: Main Stage >>> >>> Vector 8 7 250992 0. >>> Vector Scatter 2 0 0 0. >>> Distributed Mesh 2 0 0 0. >>> Star Forest Bipartite Graph 4 0 0 0. >>> Discrete System 2 0 0 0. >>> Index Set 4 4 83136 0. >>> IS L to G Mapping 2 0 0 0. >>> Viewer 2 1 784 0. >>> >>> ======================================================================================================================== >>> >>> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which their >> experiments lead. >> -- Norbert Wiener >> > >
