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
