[Zope-dev] Infuriating ZClass registry Heisenbug

Evan Simpson evan@4-am.com
Wed, 11 Dec 2002 10:24:16 -0600


Shane Hathaway wrote:
> Shot in the dark #2: Does it enter the ClassFactory function in 
> Zope.ClassFactory?  That's part of the ZClass magic... although there 
> are two ways that the pickler tries to load classes.  ZODB only tries to 
> load Persistent instances as ZClasses.  If there are things inside the 
> pickles that are not Persistent, yet come from a ZClass, ZODB will not 
> treat them kindly.

As far as I can tell, it doesn't enter *any* Python code.  Unless 
there's some other reason for pdb to be unable to step into it, it seems 
to execute only C code right up to the ImportError.  By contrast, I 
*was* able to trace through ClassFactory when it loaded the BTree -- the 
trace would then fail when loading the first Bucket.  Apparently small 
OOBTrees store their state differently, because the trace fails on the 
OOBTree load now, and I can do unpickler.noload() and see the state 
tuple with all the keys and "None" where the ZClasses should be.

> Shot in the dark #3: Unfortunately, there's one bit of ZODB that I still 
> don't fully understand, and that's setklassstate().  You might be 
> running into this somehow.  I'd hazard a guess that the latest 
> cPickleCache does not do the right thing with setklassstate(), since no 
> one has committed to maintain that part.  Ugh, we need unit tests for that.

I had never heard of it -- I'll have to take a peek.

> Here's a simple suggestion: after loading the site and browsing a few 
> pages involving ZClasses, flush the ZODB cache and see if the bug 
> appears right away.  If so, it's probably occurring as a result of 
> deactivation.

I had pretty much been assuming that that was the case, but performing 
this test confirms it.  Flushing the cache breaks things immediately.