[petsc-dev] Stray PetscViewer

[Barry Smith]

  Dave,

     This is a tricky thing. Previously the -log_summary just dealt with raw file pointers for dumping its stuff. This goes against the PETSc model where you dump stuff via a viewer. Hence I changed the code, and even the name, to take a viewer as input, not a raw file pointer. So now when -log_summary data is dumped there does exist a viewer. It is destroyed later, so not truly leaked. 

     I could "cheat" and in the table generated by -log_summary handle the special case for viewer objects and decrease the number by one. Or on that line print additional information that viewer is still in use. I hate to have such a horrible if (classid == viewer) code. What do people think? Leave as is and get careful people like Dave worried about leaked objects or add special code to make it look like there is no issue?

   Thanks for pointing this out,

     Barry

On Jan 26, 2011, at 2:34 AM, Dave May wrote:

> Hi,
>  I've noticed that there is a PetscViewer object which is not being
> freed (according to log_summary).
> This is not an object being created by the user, as the simplest petsc
> program containing just PetscInitialize() PetscFinalize()
> also displays this memory leak.
> 
> Not sure when this snuck in, but I noticed it a month back and it is
> still present in the latest version I pulled yesterday.
> 
> Cheers,
>  Dave