On Dec 8, 2012, at 9:29 AM, Jed Brown 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
We can go with 1 for now??
Shri
