[ZODB-Dev] [ zodb-Bugs-555575 ] BTree.keys() failure
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 27 Jun 2002 11:51:01 -0700
Bugs item #555575, was opened at 2002-05-13 14:48
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=115628&aid=555575&group_id=15628
Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: BTree.keys() failure
Initial Comment:
Here's a "sharp" test case that fails on my box
(Windows, Python 2.1, Zope TextIndexDS9-branch).
Guido reported failure on Linux too:
. b = IOBTree()
. for i in xrange(29972): # works if 29971
. b[i] = i
. for i in xrange(30): # works if 29
. del b[i]
. b[i+40000] = i
. print 'len(b)', len(b)
. print 'len(b.keys())', len(b.keys())
. print 'b.keys()[0]', b.keys()[0] # IndexError
That does not fail using an IIBTree, but this does:
. b = IIBTree()
. for i in xrange(29972*2):
. b[i] = i
. for i in xrange(30*2):
. del b[i]
. b[i+40000*2] = i
. print 'len(b)', len(b)
. print 'len(b.keys())', len(b.keys())
. print 'b.keys()[0]', b.keys()[0] # IndexError
It's the same thing, except the trip counts have
doubled. I assume, but don't know, that this is
related to that DEFAULT_MAX_BUCKET_SIZE is twice as
large in _IIBTree.c than in _IOBTree.c.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2002-06-27 14:51
Message:
Logged In: YES
user_id=31435
A project admin should close this. I fixed all the bugs related
to this test case, in both Zope2 and Zope3. The cause was
bugs in the BTree deletion code that caused
BTree "firstbucket" pointers to become inconsistent
information instead of redundant cached-for-speed information.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-05-13 15:19
Message:
Logged In: YES
user_id=31435
Yes, I see that the first test case above fails in the same
way after s/IOBTree/OOBTree/. This isn't surprising given
how the various BTree flavors are implemented (the same
basic code gets compiled over and over, with macro
substitutions for key and value copying, and key
comparison).
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2002-05-13 14:57
Message:
Logged In: YES
user_id=35752
Does this happen for OOBTrees as well? We saw a failure
similar to this on our site after a rogue spider
created thousands of sessions (stored in a OOBTree).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=115628&aid=555575&group_id=15628