Bugfix candidate.

Two exceedingly unlikely errors in dictresize():
1. The loop for finding the new size had an off-by-one error at the
   end (could over-index the polys[] vector).
2. The polys[] vector ended with a 0, apparently intended as a sentinel
   value but never used as such; i.e., it was never checked, so 0 could
   have been used *as* a polynomial.
Neither bug could trigger unless a dict grew to 2**30 slots; since that
would consume at least 12GB of memory just to hold the dict pointers,
I'm betting it's not the cause of the bug Fred's tracking down <wink>.

diff --git a/Objects/dictobject.c b/Objects/dictobject.c
index b465a219efa032e0e7fdf59b22f2572e92617f3f..f6f9c96cab7b9e045ea857eb322747e1b3518c7c 100644 (file)
--- a/Objects/dictobject.c
+++ b/Objects/dictobject.c
@@ -47,7 +47,6 @@ static long polys[] = {
        268435456 + 9,
        536870912 + 5,
        1073741824 + 83,
-       0
 };
 
 /* Object used as dummy key to fill deleted entries */
@@ -373,8 +372,10 @@ dictresize(dictobject *mp, int minused)
        register dictentry *newtable;
        register dictentry *ep;
        register int i;
+
+       assert(minused >= 0);
        for (i = 0, newsize = MINSIZE; ; i++, newsize <<= 1) {
-               if (i > sizeof(polys)/sizeof(polys[0])) {
+               if (i >= sizeof(polys)/sizeof(polys[0])) {
                        /* Ran out of polynomials */
                        PyErr_NoMemory();
                        return -1;