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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4