Marc-Andre Lemburg added the comment:

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.

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

Professional Python Services directly from the Source  (#1, Nov 22 2012)
>>> Python Projects, Consulting and Support ...
>>> mxODBC.Zope/Plone.Database.Adapter ...
>>> mxODBC, mxDateTime, mxTextTools ...

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: 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


Python tracker <>
Python-bugs-list mailing list

Reply via email to