Barry Smith <[email protected]> writes: > So the problem doesn't appear in any test, you have to write a silly > example to demonstrate it?
No, I wrote that snippet to have a _reduced_ test case, but it's not a hypothetical because existing tests were failing. KSP tutorials runex55_Classical crashes reliably on my machine for this reason. In some cases, the old memory doesn't get overwritten and the next parent traversal succeeds, so running in Valgrind would be a quicker way to find other examples. The pattern is used in other places. > How about instead removing TSSetSNES, SNESSetKSP, KSPSetPC and any > other weird shit that I put in that shouldn't be there away? No, we use these to share an inner component without disrupting the outer context. For example, we make a KSP for eigenvalue estimation and use the inner PC. My eigen-analysis plugin makes a SLEPc EPS and uses the PC from the primary solve. In TS, we create an inner TS as a starting method for DAE when using a method with explicit first stage, or with methods that always require a starting method. > > I think it is important that we maintain internally information > about relationships of objects. I would rather fix the problem > rather than remove the problem by removing the information. > > Note that each object can have at most one parent at a time. This is not true because we reuse "child" components, see above. The parent-child relationship is surely a DAG, and I'm only hopeful, but not confident, that it doesn't have cycles. If you want to have a strong parent-child relationship, then it should be *enforced* by abandoning reference counting and instead giving each object a single exclusive "owner". (I'm not actually serious; it's not feasible for objects to have unique "parents" in general.) > We could even restrict it so that an object can only have one > parent ever. > > I think we can manage everything by simply having each object > maintain a list of children and updating that list as children are > destroyed and removing the parent reference when the parent is > destroyed. I will prepare a branch to add this functionality. Use > of memory would only ever be assigned to one parent so it would not > be double counted. What is the great value that you will gain by holding this relationship? It makes the model lots more complicated, and debugging that counting, accidental cycles, and the like will be much worse than debugging the existing reference counting (which can be hairy, but at least debuggers do a decent job).
pgp5yCj18cNLc.pgp
Description: PGP signature
