[Python-Dev] Defending against stack overflow (was Sandboxing Python)
Maciej Fijalkowski
fijall at gmail.com
Mon Mar 5 04:45:50 CET 2012
More information about the Python-Dev mailing list
Mon Mar 5 04:45:50 CET 2012
- Previous message: [Python-Dev] Defending against stack overflow (was Sandboxing Python)
- Next message: [Python-Dev] Sandboxing Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Defending against stack overflow (was Sandboxing Python)
- Next message: [Python-Dev] Sandboxing Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list