Commit a60a5faa authored by Tim Peters's avatar Tim Peters

New testThreeEmptyBucketsNoSegfault, to test the scenario in

    "sporadic Zope crashes"
    http://collector.zope.org/Zope/553

This is much like the test of the same name I just added to the Zope
2.6 and 2.7 branches, but reworded to use ZODB 3.3isms.  The HEAD
bucket conflict resolution code is already correct in this case,
so no other code change here -- adding this test to ensure it stays
correct.
parent e272c285
......@@ -660,6 +660,35 @@ class NastyConfict(Base, TestCase):
# And the resulting BTree shouldn't have internal damage.
b._check()
# The snaky control flow in _bucket__p_resolveConflict ended up trying
# to decref a NULL pointer if conflict resolution was fed 3 empty
# buckets. http://collector.zope.org/Zope/553
def testThreeEmptyBucketsNoSegfault(self):
self.openDB()
r1 = self.db.open().root()
self.assertEqual(len(self.t), 0)
r1["t"] = b = self.t # an empty tree
transaction.commit()
r2 = self.db.open(synch=False).root()
copy = r2["t"]
# Make sure all of copy is loaded.
list(copy.values())
# In one transaction, add and delete a key.
b[2] = 2
del b[2]
transaction.commit()
# In the other transaction, also add and delete a key.
b = copy
b[1] = 1
del b[1]
# If the commit() segfaults, the C code is still wrong for this case.
self.assertRaises(ConflictError, transaction.commit)
transaction.abort()
def testCantResolveBTreeConflict(self):
# Test that a conflict involving two different changes to
# an internal BTree node is unresolvable. An internal node
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment