[petsc-dev] Memory corruption on 'master' (barry/improve-memory-logging)

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130820/47d12c93/attachment.sig>