[issue14507] Segfault with deeply nested starmap calls

Changes by Georg Brandl : -- resolution: later -> duplicate status: pending -> closed superseder: -> deeply nested filter segfaults ___ Python tracker ___ __

[issue14507] Segfault with deeply nested starmap calls

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue14507] Segfault with deeply nested starmap calls

Serhiy Storchaka added the comment: This looks as a duplicate of issue14010. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Pyt

[issue14507] Segfault with deeply nested starmap calls

Changes by Terry J. Reedy : -- versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14507] Segfault with deeply nested starmap calls

Kristján Valur Jónsson 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, including my previo

[issue14507] Segfault with deeply nested starmap calls

Mark Dickinson 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 MAXSTACK in Parser/par

[issue14507] Segfault with deeply nested starmap calls

Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14507] Segfault with deeply nested starmap calls

Raymond Hettinger 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 seems to be just a CPython issu

[issue14507] Segfault with deeply nested starmap calls

Kristján Valur Jónsson 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 down the execution mu

[issue14507] Segfault with deeply nested starmap calls

Antoine Pitrou 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 discussion of termin

[issue14507] Segfault with deeply nested starmap calls

Terry J. Reedy 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 reached is the

[issue14507] Segfault with deeply nested starmap calls

Antoine Pitrou 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 nested data st

[issue14507] Segfault with deeply nested starmap calls

Raymond Hettinger 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 less interesting (or at

[issue14507] Segfault with deeply nested starmap calls

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue14507] Segfault with deeply nested starmap calls

Antoine Pitrou 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. -- _

[issue14507] Segfault with deeply nested starmap calls

Kristján Valur Jónsson 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 function pointers, ending

[issue14507] Segfault with deeply nested starmap calls

Antoine Pitrou 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. -- __

[issue14507] Segfault with deeply nested starmap calls

Raymond Hettinger 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, perhaps memory being allocat

[issue14507] Segfault with deeply nested starmap calls

Raymond Hettinger 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 segfault. The following