Fixed in barry/fix-log_view (except for the one missing viewer object). In next for testing. Can you run your bad code with this branch and see if the problem is truly gone. Thanks Barry
On Sep 1, 2017, at 2:42 AM, Stefano Zampini <[email protected]> wrote:
As it is now, if you create any object and use PetscObjectRegisterDestroy, the output from log_view may be misleading, as it will show something like this
Memory usage is given in bytes:
Object Type Creations Destructions Memory Descendants' Mem. Reports information only for process 0.
--- Event Stage 0: Main Stage
Index Set 237 237 310852 0. IS L to G Mapping 53 35 75260 0. Application Order 2 2 2352 0. Vector 617 582 1312048 0. Vector Scatter 41 23 15088 0. .....
In this example, the objects registered for destroy where also composed with l2g maps and scatters. So the user may think of having memory leaks somewhere. But running with -malloc_dump (or under valgrind --leak-check=full) the output is clean. This is because PetscObjectRegisterDestroyAll is called after PetscLogView in PetscFinalize().
What if the reason to call PetscObjectRegisterDestroyAll after PetscLogView? Just for having PETSC_VIEWER_STDOUT_WORLD available?
-- Stefano