[issue6717] Some problem with recursion handling

Change by Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) : -- nosy: +thatiparthy ___ Python tracker ___ ___ Python-bugs-lis

[issue6717] Some problem with recursion handling

Lion Kimbro added the comment: I confirm that dragbug.py (2009-08-17!) is failing for me, almost ten years later. I'm using Python 3.6.1/win32 on Windows 10. This is really disappointing, because I have students who I'm teaching Python to via turtle, and I like to show them Python working.

[issue6717] Some problem with recursion handling

Terry J. Reedy added the comment: I reran Dino's test.py on current master on Win10 and got Traceback (most recent call last): File "f:/dev/tem/recursion_crash.py", line 23, in f() File "f:/dev/tem/recursion_crash.py", line 18, in f f() File "f:/dev/tem/recursion_crash.py", lin

[issue6717] Some problem with recursion handling

Carol Willing added the comment: Hi Gregor and others, I'm triaging 'turtle' issues. I'm recommending, if I don't hear an objection in two weeks, closing this issue with a resolution of "outdated". Thanks. -- nosy: +willingc ___ Python tracker <

[issue6717] Some problem with recursion handling

Roundup Robot added the comment: New changeset 0dfa3b09a6fe by Nick Coghlan in branch '3.2': Record a known crasher from #6717 http://hg.python.org/cpython/rev/0dfa3b09a6fe New changeset 509f7a53f8cc by Nick Coghlan in branch '3.3': Merge #6717 crasher from 3.2 http://hg.python.org/cpython/rev/5

[issue6717] Some problem with recursion handling

Dino Viehland added the comment: One thought might be to do a recursion check (and maybe for multiple frames) when entering a try rather than incrementing the recursion limit to allow the handlers to run. That would cause the exception to be more likely taken before you run the code which

[issue6717] Some problem with recursion handling

Dino Viehland added the comment: Maybe there just needs to be a max that it will bump it up? FYI this isn't actually causing any problems for me, I just ran into it while doing IronPython development and was surprised to be able to crash the interpreter w/ pure Python code, and my crash loo

[issue6717] Some problem with recursion handling

Antoine Pitrou added the comment: > FYI this isn't actually causing any problems for me, I just ran into it > while doing IronPython development and was surprised to be able to > crash the interpreter w/ pure Python code, and my crash looked awfully > similar to this bug. I agree that crashin

[issue6717] Some problem with recursion handling

Antoine Pitrou added the comment: > It's catching the exception when it invokes x, but the recursion > enforcement should happen at a method prolog, including at the > invocation of g. Therefore if we're at or beyond the recursion limit > when invoking the trace handler the limits should still

[issue6717] Some problem with recursion handling

Dino Viehland added the comment: It's catching the exception when it invokes x, but the recursion enforcement should happen at a method prolog, including at the invocation of g. Therefore if we're at or beyond the recursion limit when invoking the trace handler the limits should still be enf

[issue6717] Some problem with recursion handling

Antoine Pitrou added the comment: > Antoine: If you're looking at my test.py then my expectation is that > this doesn't crash because a RuntimeError should be raised when the > maximum recursion limit is hit, and then the trace handler should be > uninstalled because it leaks an exception. I do

[issue6717] Some problem with recursion handling

Dino Viehland added the comment: Antoine: If you're looking at my test.py then my expectation is that this doesn't crash because a RuntimeError should be raised when the maximum recursion limit is hit, and then the trace handler should be uninstalled because it leaks an exception. And that's

[issue6717] Some problem with recursion handling

Antoine Pitrou added the comment: Yes, this is all by design. The interpreter *has* to stop: either it stops in a controlled way (the fatal error) or the stack is blown and it crashes. If you think the fatal error (basically a C abort() call) should be replaced with another way of exiting, pl

[issue6717] Some problem with recursion handling

Changes by Philippe Devalkeneer : -- nosy: +flupke ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue6717] Some problem with recursion handling

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue6717] Some problem with recursion handling

Changes by Terry J. Reedy : -- versions: +Python 3.3 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6717] Some problem with recursion handling

Dino Viehland added the comment: I ran into a similar issue and believe I have a simpler repro. I think the issue here might be that when you take a stack overflow inside of a sys.settrace handler that you can then later violate the stack depth. The attached test.py has no dependencies and

[issue6717] Some problem with recursion handling

Emmanuel Decitre added the comment: Issue reproduceable on 3.2 (r32:88445) with drag_bug_is_nesting_events.py -- nosy: +Emmanuel.Decitre ___ Python tracker ___ __

[issue6717] Some problem with recursion handling

Peter Wentworth added the comment: Oops, I wish I hadn't asked that silly question about the global declaration! Here is the tweaked file... -- Added file: http://bugs.python.org/file22073/drag_bug_is_nesting_events.py ___ Python tracker

[issue6717] Some problem with recursion handling

Changes by Peter Wentworth : Removed file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py ___ Python tracker ___ ___ Python-bug

[issue6717] Some problem with recursion handling

Peter Wentworth added the comment: Attached is a crashing program that shows that the event handler is called again before activation of the prior instance has completed. I also have a second turtle that queues the nested events. It doesn't crash the system, at least. Perhaps someone can al

[issue6717] Some problem with recursion handling

Peter Wentworth added the comment: I can confirm the crash persists as of Python 3.1.3 on Windows, and would like to add my vote to prioritizing it. Without having delved into the code, it seems strange that the rapid stream of events is causing stack overflow / recursion limit problems. I

[issue6717] Some problem with recursion handling

Changes by Kurt B. Kaiser : -- nosy: +kbk priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue6717] Some problem with recursion handling

Gregor Lingl added the comment: I've written and appended with this message a small script using tkinter, that produces the same crash as described earlier with turtle.py: tkinter_recursion_31.py It occurs when heavily and fast dragging the red square. So the bug doesn't depent on turtle.py I

[issue6717] Some problem with recursion handling

Terry J. Reedy added the comment: For anyone trying this on another system: you must specifically click on and drag the mouse/turtle graphic. Running from IDLE edit, I get no traceback in the Shell Window, unlike with the script I attached to #7074 and now here. While I am closing the latter as

[issue6717] Some problem with recursion handling

Changes by R. David Murray : -- components: +Tkinter priority: -> normal type: -> crash versions: +Python 3.2 ___ Python tracker ___

[issue6717] Some problem with recursion handling

R. David Murray added the comment: With py3k trunk on Gentoo Linux after less than a second of flailing the cursor around on the screen I got: rdmur...@partner:~/python/py3k>./python dragbug.py Fatal Python error: Cannot recover from stack overflow. zsh: abort ./python dragbug.py ---

[issue6717] Some problem with recursion handling

New submission from Gregor Lingl : I suspect that there is some deeper (more severe) issue behind the problem I describe below. I've observed the following on Windows only. Didn't try it with different OSs running dragbug.py shows different behaviour with Python 3.1 compared to Python 2.6: Runn