On 22.11.2012 10:26, Alexis Daboville wrote:
> 
> Alexis Daboville added the comment:
> 
> I don't think it can be "fixed" with sys.setrecursionlimit for a few reasons:

I think you misunderstood. The suggestion was to use the sys
function to check whether the segfault is indeed caused by
the stack and where a more suitable would be.

In order to check this, you need to set a new limit and then
compile the example script. If this results in a RuntimeError
instead of a segfault for some new value of the limit, we'd
know that the problem is caused by the stack use of the compiler.

> * I think the issue arises when the AST is built. Otherwise if we put code before the if it would execute. But that's not the case (try putting a print('hello') before the if and it won't print anything).
>   - This also means that you cannot directly call sys.setrecursionlimit in the file with the elifs.
>   - Though we can set recursion limit using a second file which will then import the elifs file: I tried with different limits and CPython still crash in the same way (and always with the same number of elifs, roughly, because I didn't binary search for the exact amount of elifs).
>   - sys.setrecursionlimit controls the stack size of the running Python program, while here we break C stack directly before running Python bytecode.

It is also used by the compiler. From symtable.c:

/* When compiling the use of C stack is probably going to be a lot
   lighter than when executing Python code but still can overflow
   and causing a Python crash if not checked (e.g. eval("()"*300000)).
   Using the current recursion limit for the compiler seems too
   restrictive (it caused at least one test to fail) so a factor is
   used to allow deeper recursion when compiling an expression.

   Using a scaling factor means this should automatically adjust when
   the recursion limit is adjusted for small or large C stack allocations.
*/
#define COMPILER_STACK_FRAME_SCALE 3

We may have to adjust that scaling factor.

> * When recursion limit is hit, an exception is raised, there's no segfault:
>>>> def f():
> ...     f()
> ...
>>>> f()
> # plenty of omitted lines
> RuntimeError: maximum recursion depth exceeded
>>>>
> * Having a RuntimeError raised would be nice, though 'maximum recursion depth exceeded' may not be the best possible error message as from a 'Python user' POV there's no recursion here.

You should be seeing "maximum recursion depth exceeded during compilation"
if the RuntimeError is generated by the compiler - as Christian did for
debug builds.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/