classification
Title: Python 3 aborts with this code.
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.2, Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Interpreter aborts when chaining an infinite number of exceptions
View: 6028
Assigned To: Nosy List: Ramchandra Apte, benjamin.peterson, georg.brandl, roger.serwy, terry.reedy
Priority: normal Keywords:

Created on 2011-12-21 05:54 by Ramchandra Apte, last changed 2011-12-24 22:45 by terry.reedy. This issue is now closed.

Messages (19)
msg149956 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2011-12-21 05:54
When you run the following code, Python 3 (not Python 2) crashes.
Interestingly, Python 2.7 doesn't seem to be affected and correctly raises an error about recursion ( so this must be a regression ).
The code's recursion should be detected and Python should raise a RuntimeError about recursion.

def recurse():
    try:raise Exception #An arbitary exception
    except Exception:recurse()

After running this code Python 3 says "Fatal Python error: Cannot recover from stack overflow." and then Python aborts .
In Jython, this code doesn't crash it.
msg149957 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-21 06:15
Python isn't crashing; it's bailing out of an impossible situation. It's not clear what the correct behavior is, since you're basically preventing Python from aborting the recursive behavior.
msg149958 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2011-12-21 06:24
But Python 2 doesn't crash after running the code.
msg149959 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2011-12-21 06:26
Oops, to reproduce this bug after running the code run "recurse()".
msg150006 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-21 16:14
The behavior of Python 2 is not anymore correct than that of Python 3.
msg150089 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2011-12-22 11:51
Well, I expect Python 3 to raise RuntimeError about recursion not to segfault.
msg150095 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-22 14:46
There is no place for it to raise a RuntimeError which will continue to propogate!
msg150101 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2011-12-22 16:01
With Python 2, I can inspect the error to see where it occurred using traceback. With Python 3, I'd need to use gdb.
msg150198 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-12-23 22:03
@OP: As you yourself wrote, this is an abort, not a segfault.  It is not a crash; it is a controlled exit of the Python executable.

@Benjamin: I don't really understand your reasoning: what is preventing Python to raise the error during the except clause?
msg150199 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-23 22:40
Nothing, but that would be pointless; the recursion would just start again.
msg150205 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-12-24 03:28
When I run this with 3.2.2 IDLE, from an edit window, I get an MSVC++ Runtime Library window: "Runtime Error! .../pythonw This application has requested termination in an unusual way...". When I close that, IDLE continues. So I would say that this is not a crash and not even a bug, but a particular choice of undefined behavior given infinite loop code. So we have no obligation to change it. I presume the change from 2.x is a side-effect of a change to improve something else.

def recurse(): recurse()
recurse()

does print "RuntimeError: maximum recursion depth exceeded" but only after printing a    l  o  n  g    traceback. So for running from IDLE, I at least half prefer the immediate error box with no traceback.
msg150208 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2011-12-24 04:12
@Terry
IDLE restarts python (like in the menu entry "Restart Shell") when the Python process dies no matter how the Python process dies.
So this issue is a valid bug.
msg150217 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2011-12-24 07:25
This is identical to issue6028 and may be related to issue3555.
msg150227 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-12-24 09:33
> Nothing, but that would be pointless; the recursion would just start again.

Why?
msg150229 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-24 14:50
2011/12/24 Georg Brandl <report@bugs.python.org>:
>
> Georg Brandl <georg@python.org> added the comment:
>
>> Nothing, but that would be pointless; the recursion would just start again.

Because it would be caught in the function call above in the stack?
msg150230 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-12-24 14:51
Would it?
msg150231 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-24 14:52
2011/12/24 Georg Brandl <report@bugs.python.org>:
>
> Georg Brandl <georg@python.org> added the comment:
>
> Would it?

(<class 'Exception'>,)
msg150232 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-12-24 14:54
Basically forget my last 3 messages.
msg150238 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-12-24 22:45
@maniram I know what IDLE does. For the tracker, a 'bug' is a discrepancy between doc and behavior. According to the doc, a recursion loop should continue forever, just like an iteration loop ;=).

Anyway, Roger is right, this is a duplicate of #6028, which has at least a preliminary patch.
History
Date User Action Args
2011-12-24 22:45:47terry.reedysetstatus: open -> closed
resolution: duplicate
superseder: Interpreter aborts when chaining an infinite number of exceptions
messages: + msg150238
2011-12-24 14:54:09benjamin.petersonsetmessages: + msg150232
2011-12-24 14:52:45benjamin.petersonsetmessages: + msg150231
2011-12-24 14:51:21georg.brandlsetmessages: + msg150230
2011-12-24 14:50:16benjamin.petersonsetmessages: + msg150229
2011-12-24 09:33:41georg.brandlsetmessages: + msg150227
2011-12-24 09:33:25georg.brandlsetmessages: - msg150226
2011-12-24 09:32:45georg.brandlsetmessages: + msg150226
2011-12-24 07:25:24roger.serwysetmessages: + msg150217
2011-12-24 04:12:38Ramchandra Aptesetmessages: + msg150208
2011-12-24 03:28:50terry.reedysettype: crash -> behavior

messages: + msg150205
nosy: + terry.reedy
2011-12-23 22:40:22benjamin.petersonsetmessages: + msg150199
2011-12-23 22:03:09georg.brandlsetnosy: + georg.brandl

messages: + msg150198
title: Python 3 crashes (segfaults) with this code. -> Python 3 aborts with this code.
2011-12-22 16:01:58roger.serwysetnosy: + roger.serwy
messages: + msg150101
2011-12-22 14:46:53benjamin.petersonsetmessages: + msg150095
2011-12-22 11:51:56Ramchandra Aptesetmessages: + msg150089
2011-12-21 16:14:54benjamin.petersonsetmessages: + msg150006
2011-12-21 06:26:15Ramchandra Aptesetmessages: + msg149959
2011-12-21 06:24:42Ramchandra Aptesetmessages: + msg149958
2011-12-21 06:15:40benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg149957
2011-12-21 06:11:21Ramchandra Aptesettitle: Python 3 crashes with this code. -> Python 3 crashes (segfaults) with this code.
2011-12-21 05:55:20Ramchandra Aptesettitle: Python crashes with this code. -> Python 3 crashes with this code.
2011-12-21 05:54:52Ramchandra Aptecreate