Tom Karzes <kar...@sonic.net> added the comment:
I tested this some more, and one thing became clear that I hadn't realized
before: This bug has nothing to do specifically with generators (as I had
thought), but is in fact due purely to the recursion limit.
I created a recursive test program that doesn't use generators at all, and ran
into the exact same problem (at only a slightly higher recursion level). I am
attaching that test case as recurse_bug4.py. Here's a sample failing
invocation:
% ./recurse_bug4.py 20000
Segmentation fault (core dumped)
%
On my system, the cutoff point for this one seems to be around 17600, roughly
1100 higher than for the generator example.
What surprises me about this is the Python implementation uses recursion to
implement recursion in Python apps. I would have thought that it would use
heap memory for something like this, and as a result only require a fixed
amount of stack. That would clearly have major advantages, since it would
decouple recursion limits in Python code from stack limits on the platform.
On the other hand, now that I understand that this is in fact the result of a
system limit, I was *very* easily able to work around the problem! I simply
disabled the stack limit. From csh:
% unlimit stacksize
%
Then:
% ./gen_bug3.py 100000
100000
%
and:
% ./recurse_bug4.py 100000
100000
%
So you were right, this was due solely to the default stack limit on my system,
and not a bug in the Python implementation. And it was also very easy to
remove that limit. Hopefully something similar can be done on Windows (which I
know very little about).
Thank you for your help!
----------
Added file: https://bugs.python.org/file49487/recurse_bug4.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41912>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
