[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.