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.
*/
#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/
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16527>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
