[ZODB-Dev] Tracking down a freeze (deadlock?)

[Florent Guillaume]

Tim Peters wrote:
>>Apparently (I am still not yet sure), a "__del__" in a persistent class
>>leads to a severe failure -- a very difficult to detect deadlock.
> 
> Florent seems to believe he has such a case.  It's obviously not the case
> that every __del__ method leads to deadlock (as you've noted before too).

In this case the code of the __del__ method started by doing something like:
    mltool = self.portal_mailinglists
which reawakened self and led to the deadlock shown in the traceback. 
The fact that mount points were used may be an aggravating factor, I 
don't know. I don't claim to understand the deadlock, I just witnessed it.

>>We have many reports of hanging Zope instances -- reports where we do not
>>know the reason. Maybe, many of those are caused by "__del__"s in
>>persistent classes.
> 
> Seems unlikely to me:  in a current Zope 2.7 release, the only persistent
> class with a __del__ method is one I added to ZODB's test suite (to verify
> that the infinite loop in the pickle cache no longer occurs).  Maybe some
> popular product has this problem?  In Florent's report, the class appeared
> to live in DICODMailingList.py, but the only reference Google finds to that
> is in Florent's message to zodb-dev.

Yes, that code isn't public. That part of the code was actually buggy 
and had never been properly tested, it was supposed to delete a related 
object and expected a context-wrapped self. It could never have worked 
as is, and has been replaced by a proper use of manage_beforeDelete.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com