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

Patrick Sanan patrick.sanan at gmail.com
Thu Aug 4 03:10:52 CDT 2016


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.

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.
>
> 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