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
>
