<br><br><div><span class="gmail_quote">On 6/27/06, <b class="gmail_sendername">Michael Hudson</b> <<a href="mailto:mwh@python.net">mwh@python.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> writes:<br><br>> If you look at that crasher, you will notice that recursion depth is set<br>> to 1 << 30 before any code is run. If you remove that setting high
<br>> setting and go with the default then the test doesn't crash and raises the<br>> appropriate RuntimeError.<br>><br>> Setting the recursion depth to such a high number will crash the<br>> interpreter even when the proper recursion checks are in place. This
<br>> doesn't seem like a legit crasher to me if it requires an insane recursion<br>> depth that would crash almost any C program that had recursion in it.<br>><br>> Anyone have any objections if I call foul on the test and remove it
<br>> without any changes to Python?<br><br>Yes, it's still a way to crash Python :-) (in fact, a problem vaguely<br>like this that made a complete test run segfault on 64-bit platforms<br>was fixed in PyPy recently).<br>
<br>More seriously, the recursion limit approach is IMHO something of a<br>hack, as the amount of bytes of C stack in between increments is<br>rather variable (try seeing how high you have to set the recursion<br>limit to when the recursion invovles
list.sort() compared to when it<br>doesn't). I don't have a fantastic idea for fixing this, but I quite<br>like having some kind of reminder of it.</blockquote><div><br><br>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.
<br><br>-Brett <br></div><br></div><br>