[Zodb-checkins] CVS: ZODB3 - NEWS.txt:1.17.2.26

[Jeremy Hylton]

Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv4658

Modified Files:
      Tag: ZODB3-3_1-branch
	NEWS.txt 
Log Message:
Edits from Tim.


=== ZODB3/NEWS.txt 1.17.2.25 => 1.17.2.26 ===
--- ZODB3/NEWS.txt:1.17.2.25	Wed Apr 30 16:37:04 2003
+++ ZODB3/NEWS.txt	Wed Apr 30 17:05:33 2003
@@ -18,7 +18,7 @@
 A number of minor reference count fixes in the object cache were
 fixed.  That's the cPickleCache.c file.
 
-It was possible that a transaction that failed in tpc_finish() to lose
+It was possible for a transaction that failed in tpc_finish() to lose
 the traceback that caused the failure.  The transaction code was fixed
 to report the original error as well as any errors that occur while
 trying to recover from the original error.
@@ -56,29 +56,22 @@
 BTrees
 ------
 
-_bucket_set():  This could leave a mapping bucket in a variety of insane
-states when the value passed in was of the wrong type (for example,
-doing
-    b[obj] = 3.7
-when b is an OIBTree).  This manifested as a refcount leak in the test
+Trying to store an object of a non-integer type into an IIBTree
+or OIBTree could leave the bucket in a variety of insane states.  For
+example, trying
+
+    b[obj] = "I'm a string, not an integer"
+
+where b is an OIBTree.  This manifested as a refcount leak in the test
 suite, but could have been much worse (most likely in real life is that
 a seemingly arbitrary existing key would "go missing").
 
-_BTree_set():  We leaked a reference to the first key of the second
-bucket when deleting the first child of a BTree node with more than one
-child.  This caused >600 int objects to leak in the OI and OO flavors
-of testRemoveSucceeds.
-
-BTree_deleteNextBucket():  This failed to decref the temp result from
-BTree_lastBucket().  In unusual cases, this could cause a chain of
-buckets to leak (the DegenerateBTree tests appeared to be the only
-ones that provoked this, and there it leaked 285 IISet buckets).  Other
-uses of BTree_lastBucket() appear to be refcount-correct.
-
-nextBTreeItems():  This was copying the value (from the next (key,
-value) pair) from the bucket into the set-iteration struct twice.  I
-don't believe this had any visible effect, it was simply pointless and
-wasted a little time (discovered by eyeball).
+When deleting the first child of a BTree node with more than one
+child, a reference to the second child leaked.  This could cause
+the entire bucket chain to leak (not be collected as garbage
+despite not being referenced anymore).
+
+Other minor BTree leak scenarios were also fixed.
 
 Tools
 -----