Repository navigation
Python 3 aborts with this code. #57853
Description
| BPO | 13644 |
|---|---|
| Nosy | @birkenfeld, @terryjreedy, @benjaminp, @serwy |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2011-12-24.22:45:47.412>
created_at = <Date 2011-12-21.05:54:52.220>
labels = ['interpreter-core', 'type-bug']
title = 'Python 3 aborts with this code.'
updated_at = <Date 2011-12-24.22:45:47.398>
user = 'https://bugs.python.org/RamchandraApte'bugs.python.org fields:
activity = <Date 2011-12-24.22:45:47.398>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2011-12-24.22:45:47.412>
closer = 'terry.reedy'
components = ['Interpreter Core']
creation = <Date 2011-12-21.05:54:52.220>
creator = 'Ramchandra Apte'
dependencies = []
files = []
hgrepos = []
issue_num = 13644
keywords = []
message_count = 19.0
messages = ['149956', '149957', '149958', '149959', '150006', '150089', '150095', '150101', '150198', '150199', '150205', '150208', '150217', '150227', '150229', '150230', '150231', '150232', '150238']
nosy_count = 5.0
nosy_names = ['georg.brandl', 'terry.reedy', 'benjamin.peterson', 'roger.serwy', 'Ramchandra Apte']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '6028'
type = 'behavior'
url = 'https://bugs.python.org/issue13644'
versions = ['Python 3.2', 'Python 3.3']
Activity
RamchandraApte commentedon Dec 21, 2011
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.
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.
[-]Python crashes with this code.[/-][+]Python 3 crashes with this code.[/+][-]Python 3 crashes with this code.[/-][+]Python 3 crashes (segfaults) with this code.[/+]benjaminp commentedon Dec 21, 2011
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.
RamchandraApte commentedon Dec 21, 2011
But Python 2 doesn't crash after running the code.
RamchandraApte commentedon Dec 21, 2011
Oops, to reproduce this bug after running the code run "recurse()".
benjaminp commentedon Dec 21, 2011
The behavior of Python 2 is not anymore correct than that of Python 3.
RamchandraApte commentedon Dec 22, 2011
Well, I expect Python 3 to raise RuntimeError about recursion not to segfault.
benjaminp commentedon Dec 22, 2011
There is no place for it to raise a RuntimeError which will continue to propogate!
serwy commentedon Dec 22, 2011
With Python 2, I can inspect the error to see where it occurred using traceback. With Python 3, I'd need to use gdb.
birkenfeld commentedon Dec 23, 2011
@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?
[-]Python 3 crashes (segfaults) with this code.[/-][+]Python 3 aborts with this code.[/+]benjaminp commentedon Dec 23, 2011
Nothing, but that would be pointless; the recursion would just start again.
terryjreedy commentedon Dec 24, 2011
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.
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.
RamchandraApte commentedon Dec 24, 2011
@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.
serwy commentedon Dec 24, 2011
This is identical to bpo-6028 and may be related to bpo-3555.
birkenfeld commentedon Dec 24, 2011
Why?
benjaminp commentedon Dec 24, 2011
2011/12/24 Georg Brandl <[email protected]>:
Because it would be caught in the function call above in the stack?
birkenfeld commentedon Dec 24, 2011
Would it?
benjaminp commentedon Dec 24, 2011
2011/12/24 Georg Brandl <[email protected]>:
(<class 'Exception'>,)
benjaminp commentedon Dec 24, 2011
Basically forget my last 3 messages.
terryjreedy commentedon Dec 24, 2011
@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 bpo-6028, which has at least a preliminary patch.