[Zodb-checkins] CVS: ZODB3/BTrees/tests - testBTrees.py:1.50

[Tim Peters]

Update of /cvs-repository/ZODB3/BTrees/tests
In directory cvs.zope.org:/tmp/cvs-serv17086/BTrees/tests

Modified Files:
	testBTrees.py 
Log Message:
BTreeItems_seek():  Even if i == pseudoindex on entry, bucket mutation
since the last call may have left us with an invalid index.  Raise
RuntimeError instead of segfaulting (or picking up random trash) if so.
A new (and previously segfaulting) test case is courtesy of Steve
Alexander.


=== ZODB3/BTrees/tests/testBTrees.py 1.49 => 1.50 ===
--- ZODB3/BTrees/tests/testBTrees.py:1.49	Tue Jan 14 17:12:40 2003
+++ ZODB3/BTrees/tests/testBTrees.py	Fri Jan 31 15:13:03 2003
@@ -770,6 +770,30 @@
         self.assertEqual(t.insert(1, 1) , 1)
         self.assertEqual(lsubtract(list(t.keys()), [0,1]) , [])
 
+    def testDamagedIterator(self):
+        # A cute one from Steve Alexander.  This caused the BTreeItems
+        # object to go insane, accessing memory beyond the allocated part
+        # of the bucket.  If it fails, the symptom is either a C-level
+        # assertion error (if the BTree code was compiled without NDEBUG),
+        # or most likely a segfault (if the BTree code was compiled with
+        # NDEBUG).
+
+        t = self.t.__class__()
+        self._populate(t, 10)
+        # In order for this to fail, it's important that k be a "lazy"
+        # iterator, referring to the BTree by indirect position (index)
+        # instead of a fully materialized list.  Then the position can
+        # end up pointing into trash memory, if the bucket pointed to
+        # shrinks.
+        k = t.keys()
+        for dummy in range(20):
+            try:
+                del t[k[0]]
+            except RuntimeError, detail:
+                self.assertEqual(str(detail), "the bucket being iterated "
+                                              "changed size")
+                break
+
 ## BTree tests
 
 class TestIOBTrees(BTreeTests, TestCase):