-
-
Notifications
You must be signed in to change notification settings - Fork 32k
crash when deleting one pair from tee() #57663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Running the following results in a Segmentation fault on Ubuntu 11.10 64-bit with both python and python3. from itertools import *
c = count()
a,b = tee(c)
for i in range(10000000):
next(a)
del(b) |
tee() uses a linked-list of teedataobject. This list is destroyed by recursive calls to teedataobject_dealloc(). Extract of the gdb trace: #5 0x08171a8e in teedataobject_clear (tdo=0xad21b394) at ./Modules/itertoolsmodule.c:412 |
Confirmed on py3k, it doesn't seem to happen with smaller values. |
Also, a check for NULL would not hurt in tee_next(): diff -r 1e0e821d2626 Modules/itertoolsmodule.c
--- a/Modules/itertoolsmodule.c Fri Nov 04 22:17:45 2011 +0100
+++ b/Modules/itertoolsmodule.c Tue Nov 22 17:24:42 2011 +0100
@@ -475,6 +475,8 @@
if (to->index >= LINKCELLS) {
link = teedataobject_jumplink(to->dataobj);
+ if (link == NULL)
+ return NULL;
Py_DECREF(to->dataobj);
to->dataobj = (teedataobject *)link;
to->index = 0; |
Here is a patch (tests included). Thank Pyry for report, Victor and Amaury for analysis. Maybe I picked up the poor names for iterators? May be exhausted and unexhausted would be better? Feel free to correct me. |
Serhiy, I only see a test in your patch, no actual modification to itertools. |
Oh, I worked on it in a different directory. Fortunately I found a temporary copy and I do not have to write all code again. Sorry. |
Please review. |
Ping. |
The patch replaces a Py_CLEAR(tdo->nextlink)
with a construct that does, basically, something like this several times:
Py_DECREF(tdo->nextlink)
tdo->nextlink which is what leads to the issues that Py_CLEAR is supposed to prevent. Therefore I think this patch is not correct. |
Good point. Here is updated patch. |
If no one objects I will commit this next week. |
New changeset f7e14a1af609 by Serhiy Storchaka in branch '3.2': New changeset eff2a7346243 by Serhiy Storchaka in branch '3.3': New changeset 02d7a127fdfb by Serhiy Storchaka in branch 'default': New changeset 62f2d3f6015e by Serhiy Storchaka in branch '2.7': |
New changeset 4ee8d38398d4 by Serhiy Storchaka in branch '2.7': New changeset d391b2849a51 by Serhiy Storchaka in branch '3.2': New changeset 2258b4d89c9f by Serhiy Storchaka in branch '3.3': New changeset 1f57fb5e1e8e by Serhiy Storchaka in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: