RE: [pooma-dev] reference loop with updaters

[Stephen Smith]

I thought I'd mentioned this issue already in a previous
email.  Anyway, the solution to this issue in the old field
code was to not copy the updaters when the boundary condition
copies the subject field.  (FieldBCondBase uses the tag
DontCopyBoundaryConditions when initializing the subject
member.)  This solution would cause problems for Blanca,
because they use updaters for relationships and the
relationships are supposed to trigger the updaters of
their subjects to make sure all the necessary relationships
are fired.  I believe that Scott is working on incorporating
the Blanca relationship code into the r2 updaters, and will
probably have to address this issue at some point.

A complete solution would have to examine the Blanca
relationship code.  Supporting weak references for
the ref-counted block pointer from a field to its
updaters for those fields inside other updaters would
probably work.

This problem is serious and on the list of issues to
be addressed.  You can always configure with --no-pool,
to test codes with the new field for now.  (Purify will
still complain about the pile of fields that aren't deleted,
though.)

    Stephen

-----Original Message-----
From: Julian Cummings [mailto:address@hidden]
Sent: Tuesday, April 10, 2001 5:38 PM
To: address@hidden
Subject: [pooma-dev] reference loop with updaters

Hi All,

I got a little sidetracked today when I noticed that a few
of the NewField test codes (BasicTest1 and FieldTour1)
dump core at the end, during object cleanup.  This happens
because the Pool class detects that not all the pooled memory
has been freed.  After a fair bit of detective work, I have
determined that this is due to a reference-counting loop
between Fields and Updaters.

When you add an Updater to a Field, the Updater stores a
copy of the Field in UpdaterRetargetBase.  The Updater is
added to an UpdaterList stored in the FieldEngineBase
base class of the FieldEngine inside the Field.  Thus, there
is a circular loop in the reference counting.  When the Field
is destroyed at the end of the program, it calls the destructor
for its FieldEngineBase.  The FieldEngineBaseData referred
to by the FieldEngineBase does not get destroyed, however,
because there are outstanding references to it which correspond
to the copies of the Field in each Updater.

I think this is a fairly significant problem that should be fixed.
I'm not sure what the proper solution is though.  Calling
removeUpdaters() in the Field destructor causes an infinite
recursion.  Perhaps this recursion could be broken by making
the FieldEngine the subject of an Updater, rather than the Field.
Would that work?  I'm going crazy just thinking about it...

-- Julian C.

--
Dr. Julian C. Cummings                       E-mail: address@hidden
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125