[issue11383] compilation seg faults on insanely large expressions

Serhiy Storchaka added the comment: If someone will backport an issue5765 patch to 2.7, he can open a new issue or reopen issue5765. -- stage: -> resolved status: open -> closed ___ Python tracker _

[issue11383] compilation seg faults on insanely large expressions

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue11383] compilation seg faults on insanely large expressions

Changes by Serhiy Storchaka : -- components: +Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11383] compilation seg faults on insanely large expressions

Serhiy Storchaka added the comment: This bug does not reproduced on 3.3+ more as it was fixed in issue5765. But it is yet here in 2.7 and 3.2. -- versions: +Python 2.7, Python 3.2 -Python 3.4 ___ Python tracker __

[issue11383] compilation seg faults on insanely large expressions

Changes by Serhiy Storchaka : -- resolution: -> duplicate superseder: -> stack overflow evaluating eval("()" * 3) ___ Python tracker ___ ___

[issue11383] compilation seg faults on insanely large expressions

Serhiy Storchaka added the comment: Isn't it a duplicate of issue5765? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bu

[issue11383] compilation seg faults on insanely large expressions

Nick Coghlan added the comment: One caveat on this idea: it may not be possible to use the standard recursion limiting functions here, since the Python level recursion limit is generally set quite low (1000 by default on my Fedora system). While this crash *is* a design flaw in our compiler im

[issue11383] compilation seg faults on insanely large expressions

Nick Coghlan added the comment: I've started looking into what would be needed to fix this. The basic problem is that the compilation process involves many recursive operations, but doesn't contain *any* calls to the recursion control functions (http://docs.python.org/3/c-api/exceptions.html#r

[issue11383] compilation seg faults on insanely large expressions

SilentGhost added the comment: 10**6 on the other hand seem to do the job -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue11383] compilation seg faults on insanely large expressions

SilentGhost added the comment: 100k is, apparently, not enough on my system (linux2). test_crashers now fails. Are any system-specific details needed? -- nosy: +SilentGhost ___ Python tracker

[issue11383] compilation seg faults on insanely large expressions

Changes by Terry J. Reedy : -- type: -> crash versions: +Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue11383] compilation seg faults on insanely large expressions

Nick Coghlan added the comment: Updated Lib/test/crashers/compiler_recursion.py to refer back to this issue. (As well as making it actually crash again on my system - apparently an expression nested 59k deep wasn't enough to kill the stack here, so I bumped it to 100k) -- __

[issue11383] compilation seg faults on insanely large expressions

New submission from Nick Coghlan : ~/devel/py3k$ ./python -c "compile('1*'*10+'1', 'broken', 'eval')" Segmentation fault Going by the gdb stack trace we're blowing the stack due to the recursive descent in "compiler_visit_expr". -- messages: 129950 nosy: ncoghlan priority: normal s