Closed jeff-cohere closed 2 years ago
From @knepley (in #222):
It is not the backend (it was my comment trying to understand the PETSc convention). It is very likely that we either a) have something else keeping the DM alive, like an unfreed Vec, or b) have a reference cycle. However, both of those would mean there is at least one more thing unfreed.
(From #222 )
If you run
valgrind
on one of the TH demos, you can see that data withintdy->dm
is leaked, in spite of the fact thatDMDestroy
is called on this DM duringTDyDestroy
:From
demo/th
:Valgrind says (among other things):
I have verified that this is not related to DM distribution, and that for a serial run, the leak appears, and the DM created with
DMPlexCreate
(withinTDySetFromOptions
) has the same address as that passed toDMDestroy
.Finally, I don't know whether this is related, but in the version of PETSc we're currently using I see the following at the end of DMDestroy (in dm.c):
This suggests that we could have a dangling reference to the DM somewhere.