Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit b7f17e4

Browse files
committed
Found another memory leak in longrangeiter. And redo the previous correction
without calling PyType_Ready(). Question 1: Should the interpreter register all types with PyType_Ready()? Many types seem to avoid it. Question 2: To reproduce the problem, run the following code: def f(): while True: for a in iter(range(0,1,10**20)): pass f() And watch the memory used by the process. How do we test this in a unittest?
1 parent 519a042 commit b7f17e4

2 files changed

Lines changed: 2 additions & 4 deletions

File tree

Objects/object.c

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1509,9 +1509,6 @@ _Py_ReadyTypes(void)
15091509

15101510
if (PyType_Ready(&PyStdPrinter_Type) < 0)
15111511
Py_FatalError("Can't initialize StdPrinter");
1512-
1513-
if (PyType_Ready(&PyRange_Type) < 0)
1514-
Py_FatalError("Can't initialize 'range'");
15151512
}
15161513

15171514

Objects/rangeobject.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,7 @@ range_dealloc(rangeobject *r)
107107
Py_DECREF(r->start);
108108
Py_DECREF(r->stop);
109109
Py_DECREF(r->step);
110-
Py_Type(r)->tp_free(r);
110+
PyObject_Del(r);
111111
}
112112

113113
/* Return number of items in range (lo, hi, step), when arguments are
@@ -482,6 +482,7 @@ longrangeiter_dealloc(longrangeiterobject *r)
482482
Py_XDECREF(r->start);
483483
Py_XDECREF(r->step);
484484
Py_XDECREF(r->len);
485+
PyObject_Del(r);
485486
}
486487

487488
static PyObject *

0 commit comments

Comments
 (0)