[ZCM] [ZC] 1208/ 6 Resolve "Infinite loop in cPickleCache"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1208 Update (Resolve) "Infinite loop in cPickleCache"
 Status Resolved, Database/bug medium
To followup, visit:
  http://zope.org/Collectors/Zope/1208

==============================================================
= Resolve - Entry #6 by tim_one on May 19, 2004 6:48 pm

 Status: Accepted => Resolved

I checked in implementations of this approach, on the 2.7 branch and on the HEAD, along with a new test that indeed runs forever without the patch.

The approach clearly squashes the bug.  The only downside I see is that every persistent object in the connection accessed during the setattr or getattr (depending on which branch we're talking about) calls, or from any __del__ methods, may not be visited by scan_gc_items() during its current run:  while the approach stops anything from getting visited twice, it can also stop such objects from getting visited at all.  That may be theoretically inelegant, but I don't think it's a practical drawback.
________________________________________
= Comment - Entry #5 by tim_one on May 14, 2004 11:52 am

Thanks, Toby!  I'll pick this up and try to get it into 2.7.1.
________________________________________
= Comment - Entry #4 by htrd on May 14, 2004 11:34 am

I worked on this ages ago, but dont have the time to polish it....

I have comitted a fix for this for an old version of zodb, on the branch toby_terminator_branch in CVS. It works for me, but I wont have time for:
1. tests
2. porting to the current development branch
3. auditing for any undesired side effects

________________________________________
= Comment - Entry #3 by tim_one on May 14, 2004 11:31 am

Noting that Toby Dickenson appears to be working on a fix for this, on toby_terminator_branch (in CVS, not SVN).
________________________________________
= Assign - Entry #2 by tim_one on May 14, 2004 11:19 am

 Supporters removed: jeremy

Removed Jeremy as a supporter.
________________________________________
= Request - Entry #1 by tim_one on Jan 27, 2004 2:03 pm

 Status: Pending => Accepted

 Supporters added: jeremy, tim_one

As discussed on ZODB-dev, if a persistent object has a __del__ method that refers to an attribute of self, then attempting to ghostify it can unghostify it again, and move it to the MRU end of the ring as a result.  This can provoke scan_gc_items() into an infinite loop, if the number of such resurrectors + the number of unghostifiable objects in the cache exceeds the cache target size (and minimizing sets the target size to 1, so it only takes one of these guys to provoke an infinite loop then).

We could, e.g., add a mark bit to objects, or break the scan loop after it's gone around a number of times equal to the initial number of ring entries.
==============================================================