[petsc-users] Using -malloc_dump to examine memory leak

Yuyun Yang yyang85 at stanford.edu
Thu Apr 18 10:06:25 CDT 2019


Just wanted to follow up on this question, thanks for your time!

Best,
Yuyun

Get Outlook for iOS<https://aka.ms/o0ukef>
_____________________________
From: Yuyun Yang <yyang85 at stanford.edu<mailto:yyang85 at stanford.edu>>
Sent: Tuesday, April 16, 2019 21:56
Subject: RE: [petsc-users] Using -malloc_dump to examine memory leak
To: Yuyun Yang <yyang85 at stanford.edu<mailto:yyang85 at stanford.edu>>, Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>>


So using -objects_dump showed nothing below the line:
The following objects were never freed
-----------------------------------------
Does that mean I’ve freed all the objects? If so, why would -malloc_dump give me a bunch of messages?

I also ran valgrind, and am getting the following error when using --track-origins=yes:
Uninitialised value was created by a stack allocation
==617==    at 0x417D66: ComputeVel_qd::computeVel(double*, double, int&, int) (fault.cpp:953)

The first argument of this function is a Petsc array (obtained from VecGetArray, and after calling this function, VecRestoreArray was called on that same object). I can’t think of a way why valgrind thinks there is an uninitialized value. Is this by any chance related to the -malloc_dump messages?

Thanks for your help on this.

Best regards,
Yuyun

From: petsc-users <petsc-users-bounces at mcs.anl.gov<mailto:petsc-users-bounces at mcs.anl.gov>> On Behalf Of Yuyun Yang via petsc-users
Sent: Tuesday, April 16, 2019 7:30 AM
To: Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>>
Cc: petsc-users at mcs.anl.gov<mailto:petsc-users at mcs.anl.gov>
Subject: Re: [petsc-users] Using -malloc_dump to examine memory leak

Great, thank you for the advice!

Best regards,
Yuyun

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>>
Sent: Tuesday, April 16, 2019 5:54:15 AM
To: Yuyun Yang
Cc: petsc-users at mcs.anl.gov<mailto:petsc-users at mcs.anl.gov>
Subject: Re: [petsc-users] Using -malloc_dump to examine memory leak


  Please try the flag -options_dump this tries to give a much more concise view of what objects have not been freed. For example I commented
out the last VecDestroy() in src/snes/examples/tutorials/ex19.c and then obtained:

./ex19 -objects_dump
lid velocity = 0.0625, prandtl # = 1., grashof # = 1.
Number of SNES iterations = 2
The following objects were never freed
-----------------------------------------
[0] DM da DM_0x84000000_0
      [0]  DMDACreate2d() in /Users/barrysmith/Src/petsc/src/dm/impls/da/da2.c
      [0]  main() in /Users/barrysmith/Src/petsc/src/snes/examples/tutorials/ex19.c
[0] Vec seq Vec_0x84000000_6
      [0]  DMCreateGlobalVector() in /Users/barrysmith/Src/petsc/src/dm/interface/dm.c
      [0]  main() in /Users/barrysmith/Src/petsc/src/snes/examples/tutorials/ex19.c

Now I just need to look at the calls to DMCreateGlobalVector and DMDACreate2d in main to see what I did not free.

Note that since PETSc objects may hold references to other PETSc objects some items may not be freed for which you DID call destroy on.
For example because the unfreed vector holds a reference to the DM the DM is listed as not freed. Once you properly destroy the vector you'll
not that the DM is no longer listed as non freed.

It can be a little overwhelming at first to figure out what objects have not been freed. We recommending setting the environmental variable
export PETSC_OPTIONS=-malloc_test so that every run of your code reports memory issues and you can keep them under control from
the beginning (when the code is small and growing) rather than wait until the code is large and there are many unfreed objects to chase down.

   Good luck



   Barry


> On Apr 16, 2019, at 1:14 AM, Yuyun Yang via petsc-users <petsc-users at mcs.anl.gov<mailto:petsc-users at mcs.anl.gov>> wrote:
>
> Hello team,
>
> I’m trying to use the options -malloc_dump and -malloc_debug to examine memory leaks. The messages however, are quite generic, and don’t really tell me where the problems occur, for example:
>
> [ 0]1520 bytes VecCreate() line 35 in /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
>       [0]  PetscMallocA() line 35 in /home/yyy910805/petsc/src/sys/memory/mal.c
>       [0]  VecCreate() line 30 in /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
>       [0]  VecDuplicate_Seq() line 804 in /home/yyy910805/petsc/src/vec/vec/impls/seq/bvec2.c
>       [0]  VecDuplicate() line 375 in /home/yyy910805/petsc/src/vec/vec/interface/vector.c
>
> The code is huge, so going through every single VecCreate/VecDuplicate and VecDestroy is going to be time-consuming. Meanwhile, running valgrind gave me some uninitialized values errors that don’t seem to be related to the above message (or maybe they are?).
>
> How can I use this option to debug effectively?
>
> Thanks a lot,
> Yuyun


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190418/9060869e/attachment.html>


More information about the petsc-users mailing list