Oh thank you, sorry I probably missed that! -----Original Message----- From: Smith, Barry F. <bsm...@mcs.anl.gov> Sent: Thursday, April 18, 2019 8:36 AM To: Yuyun Yang <yyan...@stanford.edu> Cc: petsc-users@mcs.anl.gov Subject: Re: [petsc-users] Using -malloc_dump to examine memory leak
Please see my mail from yesterday; perhaps it did not get through On Apr 16, 2019, at 11:56 PM, Yuyun Yang <yyan...@stanford.edu> wrote: > > > 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? No idea. If you have messages from -malloc_dump then memory has not been freed and almost always this is due to undestroyed objects. Presumably you didn't turn off logging in ./configure (nobody does that). If you use the option -objects_dump this is processed in PetscOptionsCheckInitial_Private() which is called from PetscInitialize() with #if defined(PETSC_USE_LOG) ierr = PetscOptionsHasName(NULL,NULL,"-objects_dump",&PetscObjectsLog);CHKERRQ(ierr); #endif then in inherit.c each object creation gets logged with PetscErrorCode PetscHeaderCreate_Private(PetscObject h,PetscClassId classid,const char class_name[],const char descr[],const char mansec[], MPI_Comm comm,PetscObjectDestroyFunction destroy,PetscObjectViewFunction view) { static PetscInt idcnt = 1; PetscErrorCode ierr; #if defined(PETSC_USE_LOG) PetscObject *newPetscObjects; PetscInt newPetscObjectsMaxCounts,i; #endif PetscFunctionBegin; h->classid = classid; h->type = 0; h->class_name = (char*)class_name; h->description = (char*)descr; h->mansec = (char*)mansec; h->prefix = 0; h->refct = 1; #if defined(PETSC_HAVE_SAWS) h->amsmem = PETSC_FALSE; #endif h->id = idcnt++; h->parentid = 0; h->qlist = 0; h->olist = 0; h->bops->destroy = destroy; h->bops->view = view; h->bops->getcomm = PetscObjectGetComm_Petsc; h->bops->compose = PetscObjectCompose_Petsc; h->bops->query = PetscObjectQuery_Petsc; h->bops->composefunction = PetscObjectComposeFunction_Petsc; h->bops->queryfunction = PetscObjectQueryFunction_Petsc; ierr = PetscCommDuplicate(comm,&h->comm,&h->tag);CHKERRQ(ierr); #if defined(PETSC_USE_LOG) /* Keep a record of object created */ if (PetscObjectsLog) { PetscObjectsCounts++; for (i=0; i<PetscObjectsMaxCounts; i++) { if (!PetscObjects[i]) { PetscObjects[i] = h; PetscFunctionReturn(0); } } /* Need to increase the space for storing PETSc objects */ if (!PetscObjectsMaxCounts) newPetscObjectsMaxCounts = 100; else newPetscObjectsMaxCounts = 2*PetscObjectsMaxCounts; ierr = PetscMalloc1(newPetscObjectsMaxCounts,&newPetscObjects);CHKERRQ(ierr); ierr = PetscMemcpy(newPetscObjects,PetscObjects,PetscObjectsMaxCounts*sizeof(PetscObject));CHKERRQ(ierr); ierr = PetscMemzero(newPetscObjects+PetscObjectsMaxCounts,(newPetscObjectsMaxCounts - PetscObjectsMaxCounts)*sizeof(PetscObject));CHKERRQ(ierr); ierr = PetscFree(PetscObjects);CHKERRQ(ierr); PetscObjects = newPetscObjects; PetscObjects[PetscObjectsMaxCounts] = h; PetscObjectsMaxCounts = newPetscObjectsMaxCounts; } #endif PetscFunctionReturn(0); } Then in PetscFinalize() #if defined(PETSC_USE_LOG) /* List all objects the user may have forgot to free */ if (PetscObjectsLog) { ierr = PetscOptionsHasName(NULL,NULL,"-objects_dump",&flg1);CHKERRQ(ierr); if (flg1) { MPI_Comm local_comm; char string[64]; ierr = PetscOptionsGetString(NULL,NULL,"-objects_dump",string,64,NULL);CHKERRQ(ierr); ierr = MPI_Comm_dup(MPI_COMM_WORLD,&local_comm);CHKERRQ(ierr); ierr = PetscSequentialPhaseBegin_Private(local_comm,1);CHKERRQ(ierr); ierr = PetscObjectsDump(stdout,(string[0] == 'a') ? PETSC_TRUE : PETSC_FALSE);CHKERRQ(ierr); ierr = PetscSequentialPhaseEnd_Private(local_comm,1);CHKERRQ(ierr); ierr = MPI_Comm_free(&local_comm);CHKERRQ(ierr); } } #endif Very simple code. Try -objects_dump all and see if that changes things. Otherwise you'll need to use the debugger to track why it is not printing out the undestroyed objects. > > 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? Should be unrelated to the -malloc_dump message. A "stack allocation" is usually a local variable, while the value from VecGetArray() is from the heap. Check the use of all your local variables in this function. Barry > On Apr 18, 2019, at 10:06 AM, Yuyun Yang <yyan...@stanford.edu> wrote: > > Just wanted to follow up on this question, thanks for your time! > > Best, > Yuyun > > Get Outlook for iOS > _____________________________ > From: Yuyun Yang <yyan...@stanford.edu> > Sent: Tuesday, April 16, 2019 21:56 > Subject: RE: [petsc-users] Using -malloc_dump to examine memory leak > To: Yuyun Yang <yyan...@stanford.edu>, Smith, Barry F. > <bsm...@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-boun...@mcs.anl.gov> On Behalf Of Yuyun > Yang via petsc-users > Sent: Tuesday, April 16, 2019 7:30 AM > To: Smith, Barry F. <bsm...@mcs.anl.gov> > Cc: petsc-users@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 > 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 >