[petsc-users] false-positive leak report in log_view?

Patrick Sanan patrick.sanan at gmail.com
Thu Aug 4 03:23:18 CDT 2016


On Thu, Aug 4, 2016 at 10:18 AM, Dave May <dave.mayhem23 at gmail.com> wrote:
>
>
> On 4 August 2016 at 10:10, Patrick Sanan <patrick.sanan at gmail.com> wrote:
>>
>> I have a patch that I got from Dave that he got from Jed which seems
>> to be related to this. I'll make a PR.
>
>
> Jed wrote this variant of the VTK viewer so please mark him as a reviewer
> for my bug fix.
https://bitbucket.org/petsc/petsc/pull-requests/520/petscviewervtk-dereference-dm-to-avoid/diff
>
>
>>
>>
>> On Wed, Aug 3, 2016 at 8:18 PM, Mohammad Mirzadeh <mirzadeh at gmail.com>
>> wrote:
>> > 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.
>
>
> Mohammad,
>
> I can confirm that this VTK functionality bleeds memory if you write more
> than 1 vector to disk.
>
> Cheers
>   Dave
>
>
>>
>> >
>> > On Wed, Aug 3, 2016 at 2:05 PM, Mohammad Mirzadeh <mirzadeh at gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Aug 3, 2016 at 10:59 AM, Matthew Knepley <knepley at gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Aug 2, 2016 at 12:40 PM, Mohammad Mirzadeh
>> >>> <mirzadeh at gmail.com>
>> >>> 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
>> >>
>> >>
>> >
>
>


More information about the petsc-users mailing list