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