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.
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
