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
