Felix Ulrich-Oltean wrote at 2004-5-26 10:29 +0100:
... I have copied the Data.fs, and packed it in an interactive python session, with:
fs = FileStorage('Data.fs.bak-20040512') db = ZODB.DB(fs) db.pack(days = 14.0)
The stack trace I get has unreadable stuff towards the end: ... File "/usr/local/zope/lib/python/ZODB/fspack.py", line 529, in findReachableAtPacktime todo.extend(self.findrefs(pos))
Go into this frame an look at "oid". This identified the problematic object. Unfortunately, it is a bit more complex to find it parent. For this, you must determine the oid when this oid had been added to "todo" in the function "findReachableAtPacktime".
I tried printing the value of p and got:
(Pdb) p p '((U\x0eBTrees.IOBTreeq\x01U\x08IOBucketq\x02tq\x03Nt.((J\xb7v\x15\xecUO\xc1 \xaa\x8eZ\x85\xc1 \xaa\x95?\x85\x8eZ\x85\xaf\xc1 \x84\x85\x8a\\\x95"\x93V\x81r\x8
This tells you that the problematic object is an "BTrees.IOBTree.IOBucket". Such objects are mainly used by the catalog -- for the catalog metadata and so called "unindex"es (mappings from document ids to indexed values). This means when you clear your catalog, the problem will likely go away. However, almost surely, it will resurface when you reindex the catalog -- because the primary problem comes from a bad value. You might be lucky and packing (after you cleared the catalog) may reveal the true culprit (in case the problematic value is an attribute of an object). This will fail, when all attributes are fine but some method produced the wrong value. STOP! Forget about the above ideas. Your data files seem to be physically corrupted. A case for "fsrecover".... -- Dieter