[ZODB-Dev] BTrees q [Fwd: [Zope-dev] More Transience weirdness in2.7.1b1]

[Chris McDonough]

On Wed, 2004-06-02 at 17:49, Tim Peters wrote:
> > Line 555 is the line:
> >
> >    "for key in list(self._data.keys(None, max_ts)):"
> 
> Assuming list() is the builtin list(), it seems it could only happen if the
> BTree changed size *while* list() was running.  IOW, the explicit "for" loop
> looks irrelevant to me, it's the implicit loop inside the implementation of
> list() that must be complaining.  But I don't see how that's plausibly
> possible.

"list" is indeed the list builtin.

The only thing I can think of is that simultaneous changes made in
another connection/thread are bleeding through to this connection's
state.  But as you said, that shouldn't happen.

> Of what data type are the keys of this BTree (I'm assuming self._data is
> some flavor of BTree)?

Sorry, yes, it's an IOBTree.  Its integer keys are added in
monotonically increasing order (each key represents a "timeslice",
basically the integer portion of a time.time() value).  Each of its
values is an OOBTree.

> > It doesn't appear that I am mutating the state of the _data btree when
> > iterating over its keys, values or items.
> 
> It shouldn't make any difference what you're doing in the loop guts, because
> the 'for' loop is iterating over a Python list (or so it appears), not over
> a BTree.

Yes..

> Under theory that the exception is getting raised during the list() call, I
> can't think of anything that account for it.  My head is inching toward
> compiler optimization bugs, or a flaky memory chip (etc).

Steve and I are going to try to capture the aggregate state of the
IOBTree at the time when the error begins to occur.  Maybe that will
provide more clues.  I'll also ask Steve to try to run the code on
another machine if he's got the extra hardware.

> > 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.
> 
> Not as blind as I am, pal -- no clue.  I'll try to look more later (buried
> under other stuff right now).

Thanks much and no worries, just knowing that the code isn't obviously
broken is 75% of the battle.

- C