Great, thank you for the advice! Best regards, Yuyun
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Smith, Barry F. <bsm...@mcs.anl.gov> Sent: Tuesday, April 16, 2019 5:54:15 AM To: Yuyun Yang Cc: petsc-users@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@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
