[ZODB-Dev] BTree corrupted after conflict resolution

[Tim Peters]

[John Belmonte]
> In 3.3a2, I'm getting corrupted BTrees, where BTrees.check.check
> reports that the keys are out of order.

That has a depressingly familiar ring.  Have you tried ZODB HEAD?  I ask
because there is a known thread race in 3.3a2 fixed on the HEAD, which may
(or may not) be relevant.

> The corruption never occurs when I populate the container from a
> single client, only when populated from multiple clients
> simultaneously.

There are two main historical causes for this:

1. An incorrect user-defined __cmp__ method, or plain absence of an
   explicit user-defined __cmp__ method, on the user-defined class
   of an object used as a BTree key.  I mention that first because
   it's the most common cause.

2. Bugs in the BTree implemention, ZODB implementation, or ZEO
   implementation.  All three have gotten the blame at least once.

If it's the #2 flavor, then it's important to know which OS you're using,
which Python, and how fast your box is.  The last round of these were due to
excruciatingly shy thread timing holes, so shy that they couldn't be
provoked at all on some platforms.

> I'll try to make something stand-alone that exhibits the problem.

That would be greatly appreciated!