[Python-Dev] Is Lib/test/crashers/recursive_call.py really a crasher?

[Brett Cannon]

On 6/27/06, Michael Hudson <mwh at python.net> wrote:
>
> "Brett Cannon" <brett at python.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060627/1c8750c9/attachment.html