[issue3720] segfault in for loop with evil iterator

Terry J. Reedy added the comment: Too late for 2.6.6 ;-) -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3720] segfault in for loop with evil iterator

Terry J. Reedy added the comment: The fix works for 3.1.2, giving TypeError: iter() returned non-iterator of type 'BadIterator' Too late to patch 2.5. Is there any intention of patching 2.6 before its final bug-fix release, in a couple of months? -- keywords: -needs review, patch ver

[issue3720] segfault in for loop with evil iterator

Changes by Alexander Belopolsky : -- keywords: +26backport ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue3720] segfault in for loop with evil iterator

Guido van Rossum added the comment: I'm okay with that hack for 2.6 and 2.5. -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bu

[issue3720] segfault in for loop with evil iterator

Gregory P. Smith added the comment: nice hack! :) I'm going to guess that existing code in the wild setting tp_iternext = &PyObject_GetIter is rare. I certainly can not rule it entirely out but I don't see anything in the open source world using http://www.google.com/codesearch I'd be okay

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc added the comment: Yes, a hack: What about setting tp_iternext to PyObject_GetIter? they happen to have the same signature. Yes, calling next() will call iter() instead; but an iterator is often its own iterator, and more importantly, PyIter_Check() is also called. And th

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc added the comment: Fixed in r68560 (trunk) and r68561 (py3k). Difficult to backport: extensions compiled with 2.6.x would not run on 2.6.0. -- keywords: -needs review resolution: -> fixed status: open -> pending ___ Python tr

[issue3720] segfault in for loop with evil iterator

Gregory P. Smith added the comment: Any crash is a potential security problem. This needs to be fixed in 2.6.x without breaking 2.6.0 extension compatibility. (requiring extensions to be recompiled to fix the problem for an extension is fine, but they still need to load and work normally ev

[issue3720] segfault in for loop with evil iterator

Benjamin Peterson added the comment: I think PyObject_NextNotImplemented should be renamed to _PyObject_NextNotImplemented. Aside from that, I think the patch is ready for committing. -- nosy: +benjamin.peterson ___ Python tracker

[issue3720] segfault in for loop with evil iterator

Changes by STINNER Victor <[EMAIL PROTECTED]>: -- nosy: +haypo ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3720] segfault in for loop with evil iterator

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3720] segfault in for loop with evil iterator

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11317/next-nevernull.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Oops, sorry. I have too many files opened at the same time. Here is an updated patch. I removed all the "assert(PyIter_Check(it))", our evil iterator used to make them fail anyway in debug mode; and in the case of a null function pointe

[issue3720] segfault in for loop with evil iterator

Armin Rigo <[EMAIL PROTECTED]> added the comment: Maybe the file 'next-nevernull.patch' is not complete? I don't see any change in the definition of PyIter_Check(). ___ Python tracker <[EMAIL PROTECTED]>

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Did you notice that the definition of PyIter_Check() also changed? >>> class T(object): ... def __iter__(self): return self ... >>> iter(T()) Traceback (most recent call last): File "", line 1, in TypeError: iter() returned non-ite

[issue3720] segfault in for loop with evil iterator

Armin Rigo <[EMAIL PROTECTED]> added the comment: Hacking at typeobject.c should always be done extremely carefully. I don't have time to review this patch as thouroughly as I think it needs to be. (A quick issue is that it seems to break PyIter_Check() which will always return true now, but I'

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: The next-nevernull patch is much cleaner than I expected. Nice work. The assertion in abstract.c can be changed to: assert(iter==PyObject_NextNotImplemented || PyIter_Check(iter)); Armin, are you happy with the new approach? Though "

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: It was the ajaksu2 patches that needed clean-up. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Amaury, if you decide to go forward with this, please clean-up the > patches to eliminate common subexpressions. I already considered this, but generated machine code was identical, so I chose the more readable code. > Wonder if the

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: It's not just performance -- the patch code is grotesque. Lots of code would need to be changed just before the release candidate (usually a bad idea). And the underlying problem doesn't seem to be one that has *ever* affected a real u

[issue3720] segfault in for loop with evil iterator

Daniel Diniz <[EMAIL PROTECTED]> added the comment: Raymond, I think a different solution would be great, as the performance penalty might become nasty in tight loops if we miss some detail. Regarding the possible impact, I hope we can get a better estimate since the other examples of segfaulti

[issue3720] segfault in for loop with evil iterator

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: I share Raymond's annoyance. The ultimate solution for segfaults is for bad pointer references to be catchable (trappable) the same as math errors are are now. I remember when 1/0 was fatal, not EDOM. Then the interpreter could print a trac

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Amaury, if you decide to go forward with this, please clean-up the patches to eliminate common subexpressions. Wonder if there is an alternate solution that keeps the next slot filled with something that raises an Attribute error.

[issue3720] segfault in for loop with evil iterator

Daniel Diniz <[EMAIL PROTECTED]> added the comment: Hopefully the right patch this time :/ Added file: http://bugs.python.org/file11312/itercrashers.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3720] segfault in for loop with evil iterator

Changes by Daniel Diniz <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11311/itercrashers.diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3720] segfault in for loop with evil iterator

Daniel Diniz <[EMAIL PROTECTED]> added the comment: This patch fixes Armin's list of crashers for trunk. Looking for others like them. -- nosy: +ajaksu2 versions: +Python 2.6 Added file: http://bugs.python.org/file11311/itercrashers.diff ___ Python tr

[issue3720] segfault in for loop with evil iterator

Armin Rigo <[EMAIL PROTECTED]> added the comment: The same approach can be used to segfault many more places. See http://svn.python.org/projects/python/trunk/Lib/test/crashers/iter.py . -- nosy: +arigo ___ Python tracker <[EMAIL PROTECTED]>

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Go for it. There's really no question about fixing possible segfaulters. Was just voicing my displeasure at this sort of exercise. The code has been around since at least 2.2 and hasn't caused the slightest problem. It bugs me to put

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Here are some timings, on winXP, vs2008 release build: # t.py def f(l=range(5000)): for x in l: pass # before the patch > python -m timeit -s "from t import f" "f()" 1 loops, best of 3: 159 usec per loop # after the patch > p

[issue3720] segfault in for loop with evil iterator

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: It would be a damned shame to slow down the entire language to save code that is intentionally shooting itself in the foot. EVERYONE will pay a cost -- NO ONE will benefit. My two cents. -- nosy: +rhettinger __

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: New patches, with the suggested spelling. For 3.0 and 2.6. Added file: http://bugs.python.org/file11306/baditer-2.6.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3720] segfault in for loop with evil iterator

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11305/baditer.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3720] segfault in for loop with evil iterator

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11303/baditer.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3720] segfault in for loop with evil iterator

Ismail Donmez <[EMAIL PROTECTED]> added the comment: Maybe do a s/"object is no more an iterator"/"is no longer an iterator" -- nosy: +cartman ___ Python tracker <[EMAIL PROTECTED]> __

[issue3720] segfault in for loop with evil iterator

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Good catch! Here is a patch for 3.0. -- keywords: +needs review, patch nosy: +amaury.forgeotdarc priority: -> release blocker Added file: http://bugs.python.org/file11303/baditer.patch ___ P

[issue3720] segfault in for loop with evil iterator

New submission from Gideon Smeding <[EMAIL PROTECTED]>: The attached example crashes python. The crash is caused by an evil iterator that removes its own next function. -- files: baditerator.py messages: 72119 nosy: gideon severity: normal status: open title: segfault in for loop with e