Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5765
___
___
Python-bugs-list mailing list
Nick Coghlan added the comment:
We want to minimise the risk of breaking working code. Making it easy to adjust
this recursion limit separately from the main recursion limit by using a
scaling factor is a good way to do that. It shouldn't increase the maintenance
burden in any significant
Antoine Pitrou added the comment:
Autogenerated code could easily hit the 1000 term limit - if anything,
I'd be inclined to set it *higher* than 4 rather than lower, as
breaking previously working code in a maintenance release is a bad
thing, regardless of our opinion of the sanity of that
Roundup Robot added the comment:
New changeset ab02cd145f56 by Nick Coghlan in branch '3.3':
Issue #5765: Apply a hard recursion limit in the compiler
http://hg.python.org/cpython/rev/ab02cd145f56
New changeset bd1db93d76e1 by Nick Coghlan in branch 'default':
Issue #5765: Merge from 3.3
Nick Coghlan added the comment:
You can take the scaling factor out if you really want, but it adds no real
maintenance overhead, and better reflects the real stack usage.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5765
Nick Coghlan added the comment:
However, agreed on the won't fix for 3.2 and 2.7, although I'd consider it at
least for 2.7 if someone went through and worked out a patch that applies
cleanly.
For 3.2, this really isn't the kind of thing we'd want to do in the final
regular maintenance
Antoine Pitrou added the comment:
You can take the scaling factor out if you really want, but it adds no
real maintenance overhead, and better reflects the real stack usage.
Can you also add a related snippet in
Tools/scripts/find_recursionlimit.py ?
--
Nick Coghlan added the comment:
Note: if you do take the scaling factor out, don't forget to track down the
reasons behind the original commit that added the test that broke *without* the
scaling factor.
For me, the test suite fails without it is reason enough for me to say its
needed -
Roundup Robot added the comment:
New changeset cf2515d0328b by Nick Coghlan in branch '3.3':
Issue #5765: Also check the compiler when finding the recursion limit
http://hg.python.org/cpython/rev/cf2515d0328b
New changeset 3712028a0c34 by Nick Coghlan in branch 'default':
Issue #5765: Merge
Nick Coghlan added the comment:
The sanity check in the recursion limit finding script is definitely a good
idea, so I added that (as the commits show).
For the record, running that script on the 3.3 branch with my 4 GB RAM Fedora
17 ASUS Zenbook finds a maximum recursion limit around 16800,
Mark Shannon added the comment:
I don't think there is any need for a scaling factor.
Expressions in auto-generated trees will tend to be trees of binary operator
rather lists of purely unary operators. A tree of a billion items only has a
depth of ~30.
There is no way an expression tree 1000
Antoine Pitrou added the comment:
The sanity check in the recursion limit finding script is definitely a
good idea, so I added that (as the commits show).
Didn't you make a mistake in the recursion factor there? Or is it really
10 rather than 3?
--
Nick Coghlan added the comment:
Antoine: The scaling is deliberate higher in the recursion limit finder because
we just want to ensure it hits the recursion limit (or blows the stack, if the
scaling is wrong). In the tests, I cut it finer because I wanted to ensure we
were straddling the
Andrea Griffini added the comment:
I missed all the macrology present :-( ... the following is a patch that takes
it into account (also defines a VISIT_QUIT macro to make more visible the exit
points). The handling has been also extended to visit_stmt because the macros
are shared.
Of course
Andrea Griffini added the comment:
On Mon, Aug 20, 2012 at 12:27 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Indeed I don't like the introduction of COMPILER_STACK_FRAME_SCALE.
Re-using the existing infrastructure would be much easier to maintain.
The default recursion limit is 1000,
Francisco Martín Brugué added the comment:
Just curiosity: how relate the magic numbers 10 and 2000 in
test_compiler_recursion_limit to recursion_depth and recursion_limit
Thanks!
--
nosy: +francismb
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Indeed I don't like the introduction of COMPILER_STACK_FRAME_SCALE.
Re-using the existing infrastructure would be much easier to maintain.
The default recursion limit is 1000, which should cover any non-pathological
code, IMHO.
--
nosy: +pitrou
stage:
Changes by Amaury Forgeot d'Arc amaur...@gmail.com:
Added file:
http://bugs.python.org/file26903/compiler_recursion_limit_check-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5765
___
Amaury Forgeot d'Arc added the comment:
The patch is incomplete: the VISIT macro contains a return 0; and in this
case st-recursion_depth is not decremented.
OTOH errors are never caught, so it's not necessary to do any cleanup in case
of errors.
Here is a simplified patch.
--
Mark Shannon added the comment:
I've re-reviewed Andrea's patch (I was looking over Andrea's shoulder at the
EuroPython sprint when he wrote it).
It looks good and applies cleanly.
Could someone commit it please.
--
nosy: +Mark.Shannon
___
Python
Andrea Griffini agr...@tin.it added the comment:
This is a fix for this issue.
The solution was to add two fields (recursion_depth and
recursion_limit) to the symbol table object and just increment and
check the depth in symtable_visit_expr raising a RuntimeError in case
the limit is exceeded.
Serhiy Storchaka storch...@gmail.com added the comment:
Terry, try a large constant. I can reproduce it on all versions from 2.6 to 3.3
with eval(() * 30).
--
nosy: +storchaka
versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Terry J. Reedy tjre...@udel.edu added the comment:
In 3.3.3a4 and b1, with original 3, I no longer get TypeError, but box
python(w).exe has stopped working. So either Win7, 64 bit, on machine with
much more memory makes a diffence, or something in code reverted. Is this
really a security
Serhiy Storchaka storch...@gmail.com added the comment:
I don't think that eval is used in security context.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5765
___
Terry J. Reedy tjre...@udel.edu added the comment:
On 3.1.2, WinXP, I immediately get
TypeError: 'tuple' object is not callable
so this seems to have been fixed for 3.x.
If released 2.7 is ok, we can close this.
--
nosy: +terry.reedy
versions: -Python 2.5, Python 2.6, Python 3.0
New submission from Gabriel Genellina gagsl-...@yahoo.com.ar:
Originally reported by Juanjo Conti at PyAr:
http://blog.gmane.org/gmane.org.user-groups.python.argentina/
day=20090415
Evaluating this expression causes a stack overflow, and the Python
interpreter exits abnormally:
eval(() *
Benjamin Peterson benja...@python.org added the comment:
This is a pathological case. I suppose we have to add a recursion
counter to the compiler struct.
--
nosy: +benjamin.peterson
priority: - low
___
Python tracker rep...@bugs.python.org
27 matches
Mail list logo
