[petsc-dev] malloc_dump noise from threadcomm

[Barry Smith]

   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