[petsc-dev] malloc_dump noise from threadcomm

[Jed Brown]

It won't print out the threadcomm, which is the point.
On Dec 8, 2012 10:19 AM, "Shri" <abhyshr at hawk.iit.edu> wrote:

> Will this work for threadcomm since it is not a PetscObject?
>
> Shri
> On Dec 8, 2012, at 11:56 AM, Barry Smith wrote:
>
> >
> >   I don't think any of these three things are reasonable approaches. You
> are basically saying we should not log some memory usage because it is
> annoying.
> >
> >   Much better is to have something in addition to -malloc_dump (say
> -object_dump) that is more useful. Currently -malloc_dump is a cumbersome
> way of determining which objects has not be freed.
> >
> >    I propose an alternative:   every PetscHeaderCreate() log all the
> stack frames at which it is called and a list of all objects be maintained,
> any objects that are not destroyed can have their creation stack frames
> printed at the end making it easy to find the objects that were not
> destroyed. Then we will not recommend regular users use -malloc_dump (and
> that is reserved for us and will continue to log everything properly).
> >
> >   Note that PetscHeaderCreate() uses PetscLogObjectCreate() which can
> use PetscLogPHC() (stupid name) but is apparently now a black hole. We can
> just rework PetscLogObjectCreate() to save the stack frames.
> >
> >    Barry
> >
> > On Dec 8, 2012, at 9:29 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> >
> >> threadcomm.c has this thing
> >>
> >>  for (i=0;i<PETSC_KERNELS_MAX;i++) {
> >>    ierr = PetscNew(struct
> _p_PetscThreadCommJobCtx,&PetscJobQueue->jobs[i]);CHKERRQ(ierr);
> >>
> >>
> >> that gets freed when the last PetscObject gets destroyed. But if the
> user forgets to Destroy something, this shows up as a memory leak. Since
> the relevant malloc_dump output is much higher in the stack, this is
> confusing noise, and I'd like to eliminate it. We can either
> >>
> >> 1. not log this memory at all by calling malloc or posix_memalign
> directly
> >>
> >> 2. put code into PetscFinalize that ensures that this stuff has been
> freed (very messy if user does anything weird with communicators)
> >>
> >> 3. add way to mark PetscTrMalloc'd memory as "indirect" so that it is
> not reported by default
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121208/b6ef0bab/attachment.html>