[Dieter Maurer]
> We have run in an apparent "BTrees" bug (with the "BTrees" version
> included in Zope 2.5.1).
> ...
> We will install the "BTrees" package from ZODB-3.2a1 and
> see whether the problem disappears.
> I will report back...
There are two new kinds of sanity checks you can make there:
1. somebtree._check()
This is a new method on BTree objects, which does extensive checks
of internal inter-pointer consistency. It raises AssertionError if
internal pointers have gotten into an inconsistent state. This used
to be possible in the presence of (unlikely mixtures of) inserts and
deletes.
2. from BTrees.check import check
check(somebtree)
This is a brand new checker that does a different kind of consistency
check, verifying subtle invariants involving the key *values* (not
the internal C pointers) in a BTree (or TreeSet). Again, it raises
AssertionError if anything is wrong there.
If anything is wrong,
from BTrees.check import display
display(somebtree)
displays the internal bucket structure of a BTree, to stdout. It can
clarify the nature of the damage.
There are no known ways of creating a damaged BTree anymore, short of (so
far) hypothetical scenarios involving multiple processes somehow managing to
get hold of stale data without realizing it. 3.2a1 fixes a newly-discovered
but extremely unlikely bug in BTree conflict resolution. I don't know that
it's ever been seen in real life (it was provoked by a multithreaded stress
test I wrote) -- if it ever did happen, the symptom would have been a
segfault, not silent BTree corruption.
> We try to insert a value into an "BTrees.OOBTree.OOBTree" instance
> with
>
> tree[k]= v
>
> and get an "exceptions.KeyError on 13384379A0pfvqTmtEQ".
That's indeed peculiar.
_______________________________________________
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 )
