On 6/27/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
OK, with you and Thomas both wanting to keep it I will let it be. I just won't worry about fixing it myself during my interpreter hardening crusade.
-Brett
"Brett Cannon" <[EMAIL PROTECTED]> writes:
> If you look at that crasher, you will notice that recursion depth is set
> to 1 << 30 before any code is run. If you remove that setting high
> setting and go with the default then the test doesn't crash and raises the
> appropriate RuntimeError.
>
> Setting the recursion depth to such a high number will crash the
> interpreter even when the proper recursion checks are in place. This
> doesn't seem like a legit crasher to me if it requires an insane recursion
> depth that would crash almost any C program that had recursion in it.
>
> Anyone have any objections if I call foul on the test and remove it
> without any changes to Python?
Yes, it's still a way to crash Python :-) (in fact, a problem vaguely
like this that made a complete test run segfault on 64-bit platforms
was fixed in PyPy recently).
More seriously, the recursion limit approach is IMHO something of a
hack, as the amount of bytes of C stack in between increments is
rather variable (try seeing how high you have to set the recursion
limit to when the recursion invovles list.sort() compared to when it
doesn't). I don't have a fantastic idea for fixing this, but I quite
like having some kind of reminder of it.
OK, with you and Thomas both wanting to keep it I will let it be. I just won't worry about fixing it myself during my interpreter hardening crusade.
-Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
