Changes by Georg Brandl ge...@python.org:
--
resolution: later - duplicate
status: pending - closed
superseder: - deeply nested filter segfaults
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
___
Serhiy Storchaka added the comment:
This looks as a duplicate of issue14010.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
The RuntimeError: maximum recursion depth exceeded message is normally only
triggered by pure Python recursion, so I would not have expected it here, but
there should be some sort of graceful MemoryError or somesuch rather than a
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Hmm, substituting PyIter_Next() didn't help.
There isn't much else being done in starmap.next, just a call to:
result = PyObject_Call(lz-func, args, NULL);
I'm now wondering if starmap() is tickling a bug in PyObject_Call,
Antoine Pitrou pit...@free.fr added the comment:
I'm now wondering if starmap() is tickling a bug in PyObject_Call,
perhaps memory being allocated but not checked for NULL or somesuch.
The issue is that the code paths involved here circumvent recursion checking,
so the stack blows up.
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
a = map(add, a, b) also crashes this.
a = chain(a, b) also.
If, by provisions you speak of sys.max_recursion_depth, that is only invoked
when executing python code. What's happening here is just simple c recursion
trough
Antoine Pitrou pit...@free.fr added the comment:
a = map(add, a, b) also crashes this.
a = chain(a, b) also.
If, by provisions you speak of sys.max_recursion_depth, that is only
invoked when executing python code.
There's nothing that prevents it from protecting C code.
--
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
___
Python-bugs-list
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
[Kristján]
a = map(add, a, b) also crashes this.
... What's happening here is just simple c recursion
trough function pointers, ending in stack overflow, ...
Thanks for the analysis. ISTM, this bug report is getting less and
Antoine Pitrou pit...@free.fr added the comment:
The existing sys.max_recursion_depth was put in as a defense against
the relatively common mistake of users writing a recursive function
and getting the termination code wrong. I don't think that logic
would apply to intentionally deeply
Terry J. Reedy tjre...@udel.edu added the comment:
[Raymond: I presume you meant that C iterators have not been a problem in the
wild and have done fine.]
The RuntimeError message maximum recursion depth exceeded is not exactly
correct. As Kristján implied in his first message, what has been
Antoine Pitrou pit...@free.fr added the comment:
It happens to be that recursive calls are the easiest way to do that,
but Python makes it somewhat easy to dynamically generate thousands of
different callables making thousands of non-recursive nested calls.
That's a rather pointless
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
On the other hand, Antoine is correct in that we _could_ use the existing
infrastructure and count PyIter_Next() as a recursion in the same way as
entering the ceval loop is a recursion. Extra checking in there would hardly
slow
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
ISTM this would do more harm than good. An introduce a new requirement for all
iterators, introducing new arbitrary limits and slowing down all iterators
(this is currently a simple, fast, light-weight protocol).
Also this
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14507
___
___
Python-bugs-list mailing
Mark Dickinson dicki...@gmail.com added the comment:
(A static expression with even 100 nested calls fails compilation with a
MemoryError (3.2.3).)
I don't think that's at all related to this issue: that has to do with the
fixed-size parser stack used when parsing Python code (see
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
There are other crashers we choose to ignore (involving gc.getreferrers,
bytecode hacks, ctypes, etc). I think this should go in that category
and I would be happy to add a note to that effect in the docs for tertools.
Yes,
19 matches
Mail list logo
