[ZODB-Dev] [BUG] maybe yet unknown BTREES bug

[Tim Peters]

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