This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients Sebastian.Noack, rhettinger, serhiy.storchaka
Date 2017-05-08.05:44:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1494222274.4.0.737693571344.issue30297@psf.upfronthosting.co.za>
In-reply-to
Content
Options like -fno-stack-limit and -fsplit-stack can help to avoid a crash, but they are compiler-specific and we should test how they affect the performance and memory consumption.

How can we test that the available stack is too small? This is not a part of the language, we need to use some compiler-specific tricks.

If add such check, it should be added not in the c-eval loop (or not only in the c-eval loop), but for every call of tp_iternext. Recursive call can avoid the c-eval loop. Maybe add the check in PyIter_Next() and always use PyIter_Next() instead of direct calls of tp_iternext. If the check for the stack size is not cheap we can just count the deep of the recursion and check the exact stack size every say 50 levels. And this is a good opportunity to check for KeyboardInterrupt .

In any case it would be useful to add a user specified limit on the deep of the recursion similar to sys.getrecursionlimit(). Even if the stack grows unlimitedly we don't want to fall in the swapping on unexpected deep recursion.
History
Date User Action Args
2017-05-08 05:44:34serhiy.storchakasetrecipients: + serhiy.storchaka, rhettinger, Sebastian.Noack
2017-05-08 05:44:34serhiy.storchakasetmessageid: <1494222274.4.0.737693571344.issue30297@psf.upfronthosting.co.za>
2017-05-08 05:44:34serhiy.storchakalinkissue30297 messages
2017-05-08 05:44:34serhiy.storchakacreate