<p dir="ltr">Okay with me, it's easy to change later.</p>
<div class="gmail_quote">On Dec 8, 2012 7:49 AM, "Shri" <<a href="mailto:abhyshr@mcs.anl.gov">abhyshr@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Dec 8, 2012, at 9:29 AM, Jed Brown wrote:<br>
<br>
> threadcomm.c has this thing<br>
><br>
>   for (i=0;i<PETSC_KERNELS_MAX;i++) {<br>
>     ierr = PetscNew(struct _p_PetscThreadCommJobCtx,&PetscJobQueue->jobs[i]);CHKERRQ(ierr);<br>
><br>
><br>
> 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<br>

><br>
> 1. not log this memory at all by calling malloc or posix_memalign directly<br>
><br>
> 2. put code into PetscFinalize that ensures that this stuff has been freed (very messy if user does anything weird with communicators)<br>
><br>
> 3. add way to mark PetscTrMalloc'd memory as "indirect" so that it is not reported by default<br>
<br>
We can go with 1 for now??<br>
<br>
Shri</blockquote></div>