Fatal Python error

Dave Angel davea at davea.name
Wed May 29 09:02:53 EDT 2013


On 05/29/2013 08:45 AM, Oscar Benjamin wrote:
> On 29 May 2013 12:48, Joshua Landau <joshua.landau.ws at gmail.com> wrote:
>> Hello all, again. Instead of revising like I'm meant to be, I've been
>> delving into a bit of Python and I've come up with this code:
>
> Here's a simpler example that gives similar results:
>
> $ py -3.3
> Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> def broken():
> ...   try:
> ...     broken()
> ...   except RuntimeError:
> ...     broken()
> ...
>>>> broken()
> Fatal Python error: Cannot recover from stack overflow.
>
> Current thread 0x0000058c:
>    File "<stdin>", line 3 in broken
>    File "<stdin>", line 3 in broken
> ...
>
> Under Python 2.7.5 it just goes into an infinite loop. Under Python
> 3.2.5 and 3.3.2 it crashes the interpreter as shown above.
>
> What the broken() function is doing is totally stupid: responding to a
> recursion error with more recursion. However this may indicate or be
> considered a bug in the 3.x interpreter.
>
>
> Oscar
>

More likely a bug in the 2.x interpreter.  Once inside an exception 
handler, that frame must be held somehow.  If not on the stack, then in 
some separate list.  So the logic will presumably fill memory, it just 
may take longer on 2.x .

Joshua:  Avoid doing anything complex inside an exception handler.  If 
nothing else, the exception frame is huge.  I probably would have 
spotted it except for the indentation problem triggered by html.  The 
top level code following your function didn't have any loops, so it 
wasn't a problem.

Can anyone help Joshua put his gmail into text mode?




-- 
DaveA



More information about the Python-list mailing list