[Zope] Re: Error unpickling when packing Data.fs (WAS packing with zeo error)

[Dieter Maurer]

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