A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117347.html below:

[Python-Dev] Defending against stack overflow (was Sandboxing Python)

[Python-Dev] Defending against stack overflow (was Sandboxing Python)Maciej Fijalkowski fijall at gmail.com
Mon Mar 5 04:45:50 CET 2012
On Sun, Mar 4, 2012 at 12:35 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> So, how to handle stack overflows (of the C stack)?
>> To prevent a stack overflow an exception must be raised before
>> the VM runs out C stack. To do this we need 2 pieces of info:
>> a) How much stack we've used
>> b) How much stack is available.
>
> Python has already dedicated counters for stack depth, which just need
> proper updating and conservative values. I also think that we need to
> avoid allocating large arrays on the stack in recursive functions, and
> always heap-allocate such memory, to be stack-conservative.
>
>> I think it is a reasonable aim for 3.3 that Lib/test/crashers
>> should be empty.
>
> I agree. If you have patches to review, just put me on the nosy list.
>
> Regards,
> Martin

Maybe as a point of reference. PyPy, with the interpreter being
largely modelled after CPython, automatically inserts about 750 checks
for stack exhaustion. CPython has about 15 checks so far, I suggest
looking at all the places that pypy inserts such checks is a useful
start.

Cheers,
fijal
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4