[ZODB-Dev] Re: BTrees q [Fwd: [Zope-dev] More Transience weirdness in 2.7.1b1]

[Casey Duncan]

On Wed, 02 Jun 2004 16:24:16 -0400
Chris McDonough <chrism at plope.com> wrote:

> I recently got the below message from a user of Zope sessioning.  Zope
> sessioning makes use of ZODB and BTrees, and Steve reports a somewhat
> odd (well, odd to me, at least) error.
[..]
> Line 555 is the line:
> 
>    "for key in list(self._data.keys(None, max_ts)):"
> 
> It doesn't appear that I am mutating the state of the _data btree when
> iterating over its keys, values or items.  If I'm wrong, I trust
> you'll let me know. ;-)
> 
> Guesses:  Could the BTreeItems_seek code raise this error if the data
> structure was being accessed by another thread via a different
> database connection simultaneously?  Could a suppressed conflict error
> at a past transaction commit time leave the database in such a state
> where a subsequent run through this code could wind up in this state?

This error occurs if the current offset in the current bucket in
BTreeItems_seek is either negative or greater than the largest index in
the bucket. The code assumes that this can only happen if the bucket was
mutated between calls to BTreeItems_seek. Since you are just iterating
it, no such change could be occuring (unless the reference is shared
between threads somehow), so I suspect foul play.

It might be iteresting to instrument the BTreeItemsTemplate.c in the
BTreeItems_seek() function to spew the values of i, currentoffset and
currentbucket->len when it blows up. Then you could see whether it dies
at the beginning, end or somewhere in the middle and what bucket and
index it is on when it does.

> FWIW, I have a high-concurrency test rig that exercises this code
> which I have run for 24+ hours without bumping in to the same issue,
> so I'm flying a bit blind here.

Does you test rig run multiple threads? Is ths BTree referenced from any
non-persistent global data structure (which might allow sharing across
threads)?

Interesting that restarting Zope cured this error. There must be some
inconsistency in the cached state then. Calling BTree.keys() will give
you a fresh BTreeItems object each time (with reset currentoffset and
currentbucket values), so unless something is hosed in the BTree state
itself, calling it again should start fresh.

-Casey