gh-148484: Fix memory leak of iterator in array.array constructor#148523
gh-148484: Fix memory leak of iterator in array.array constructor#148523gleb-pp wants to merge 7 commits intopython:mainfrom
Conversation
skirpichev
left a comment
There was a problem hiding this comment.
This patch ensures that the iterator is correctly DECREF'ed on all error paths after it is created.
That's not true, you ignored some case. For example, shown in the issue thread.
You're right. My previous patch missed some error paths after PyObject_GetIter(). I've updated the patch to handle the invalid typecode case (as discussed in the issue), and also added a DECREF when newarrayobject() fails, so the iterator is not leaked in these scenarios. Please let me know if you'd prefer the fix to be limited strictly to the invalid typecode path. |
skirpichev
left a comment
There was a problem hiding this comment.
LGTM.
One minor suggestion, up to other reviewers discretion.
| Py_DECREF(a); | ||
| Py_XDECREF(it); | ||
| return NULL; |
There was a problem hiding this comment.
This is a common part for most cleanups. You can add a label and use goto statements in other places.
Fix memory leak of iterator in array.array constructor
When array.array is initialized with an arbitrary iterable, an iterator is created via PyObject_GetIter().
If an invalid typecode is provided, the constructor raises a ValueError without decref'ing the iterator, leading to a memory leak.
This patch fixes the issue by adding a missing Py_XDECREF(it) before returning the ValueError.
The issue affects the fallback iterable initialization path only.
Fast-path initializers (list, tuple, bytes, bytearray, array, str) are not affected.