[issue6717] Some problem with recursion handling

[శ్రీనివాస్ రెడ్డి తాటిపర్తి]

Change by Srinivas  Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) 
:


--
nosy: +thatiparthy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Lion Kimbro]

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.

I have found a workaround which -- if this bug won't be fixed -- I propose 
mentioning in the documentation.

The work-around is something like this:

g = {"X": 0, "Y": 0}

def goto_later(x, y): g["X"] = x; g["Y"] = y

def ontick():
goto(g["X"], g["Y"])
ontimer(ontick, 10)

ondrag(goto_later)
ontimer(ontick, 10)

That way, there is no opening for recursion within the handler for the ondrag 
event.

--
nosy: +LionKimbro
versions: +Python 3.6 -Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Terry J. Reedy]

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", line 18, in f
f()
  File "f:/dev/tem/recursion_crash.py", line 18, in f
f()
  [Previous line repeated 991 more times]
  File "f:/dev/tem/recursion_crash.py", line 17, in f
print(sys.getrecursionlimit())
RecursionError: maximum recursion depth exceeded while calling a Python object

The request for a fix to get a nice traceback is out of date.

When I run Gregor's tkinter_recursionbug_31.py, I immediately get this:

f:\dev\3x>python f:/dev/tem/tk_recbug.py
Running Debug|Win32 interpreter...
f:/dev/tem/tk_recbug.py:14: DeprecationWarning: invalid escape sequence \P
  """

The closet I came to reproducing this is
>>> eval(r"f'\P{1}'")

Warning (from warnings module):
  File "", line 1
DeprecationWarning: invalid escape sequence \P
'\\P1'

When I continue and move the red box, I eventually get

Fatal Python error: Cannot recover from stack overflow.

Current thread 0x12c8 (most recent call first):
  File "F:\dev\3x\lib\enum.py", line 535 in __new__
  File "F:\dev\3x\lib\enum.py", line 307 in __call__
  File "F:\dev\3x\lib\tkinter\__init__.py", line 1431 in _substitute
  File "F:\dev\3x\lib\tkinter\__init__.py", line 1701 in __call__
  File "F:\dev\3x\lib\tkinter\__init__.py", line 1174 in update
  File "f:/dev/tem/tk_recbug.py", line 39 in move
  File "F:\dev\3x\lib\tkinter\__init__.py", line 1702 in __call__
  File "F:\dev\3x\lib\tkinter\__init__.py", line 1174 in update
  
  ...

f:\dev\3x>

and the tk window disappears.  With pythonw, the tk window disappears with no 
feedback.

There is no Windows message box, so the request to not get one is fixed 
already.  There is a (truncated) traceback (without the code lines, but they 
are viewable in the source), so the requested to get one is also fulfilled.  
The only thing left is 'Fatal Python error'.  From Antoine's messages, the 
request to get a normal exception instead is "Won't fix unless someone has a 
bright new idea".

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Carol Willing]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Roundup Robot]

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/509f7a53f8cc

New changeset 47943fe516ec by Nick Coghlan in branch 'default':
Merge #6717 crasher from 3.3
http://hg.python.org/cpython/rev/47943fe516ec

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Philippe Devalkeneer]

Changes by Philippe Devalkeneer phil.le.bienheur...@gmail.com:


--
nosy: +flupke

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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, please suggest so.

(actually, it's not the interpreter as a whole, only the current thread, but 
crashing a thread without affecting the others is probably impossible, due to 
reference leaks, resource cleanup, etc.)

--
nosy: +loewis, pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Dino Viehland]

Dino Viehland di...@microsoft.com 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 exactly what seems to happens on 
Python 2.x.  We shouldn't ever hit the OS stack limit because Python's 
recursion limit should be enforced even in the face of a sys.settrace handler.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 don't understand why you say that the trace handler leaks an
exception, since it silences it in the try ... except block.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Dino Viehland]

Dino Viehland di...@microsoft.com 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 enforced and that should be the same as the trace 
handler raising.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 enforced
 and that should be the same as the trace handler raising.

That's where 3.x is different: 3.x temporarily bumps up the recursion
limit a bit when it is first reached, in order to let various cleanup
handlers run as intended. This is a nice thing in the general case, but
means it can degenerate in more involved or desperate cases.

(although here it's not clear to me why a second recursion error occurs
after the first one)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 crashing isn't ideal, and there may be more graceful ways of 
crashing instead of abort(), so that people don't get that horrible message box 
under Windows. Suggestions welcome.

--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Dino Viehland]

Dino Viehland di...@microsoft.com 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 looked awfully similar to this 
bug.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Dino Viehland]

Dino Viehland di...@microsoft.com 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 needs some form of cleanup and then maybe the recursion limit could be a 
hard limit which can't be increased forever.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Andrew Svetlov]

Changes by Andrew Svetlov andrew.svet...@gmail.com:


--
nosy: +asvetlov

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Terry J. Reedy]

Changes by Terry J. Reedy tjre...@udel.edu:


--
versions: +Python 3.3 -Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Dino Viehland]

Dino Viehland di...@microsoft.com 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 crashes 3.x but works on 2.x.

--
nosy: +dino.viehland
Added file: http://bugs.python.org/file22365/test.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Emmanuel Decitre]

Emmanuel Decitre emm...@googlemail.com added the comment:

Issue reproduceable on 3.2 (r32:88445) with drag_bug_is_nesting_events.py

--
nosy: +Emmanuel.Decitre

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth p.wentwo...@ict.ru.ac.za 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 also explain why the handler doesn't work if I leave out 
the global declaration.

--
Added file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Changes by Peter Wentworth p.wentwo...@ict.ru.ac.za:


Removed file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth p.wentwo...@ict.ru.ac.za 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 rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth p.wentwo...@ict.ru.ac.za 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.

It suggests that tkinter is allowing new event arrivals to interrupt older 
event handling, so that the older ones remain incomplete as the newer ones pile 
up on the stack. If this is the case, it is going to lead to long-term 
instability, and needs attention.

The usual technique is to use a queue to decouple occurs now from handle 
immediately. (The OS puts the mouse and keyboard events onto window's event 
queue).  So the mainloop that services the event queue should not start 
handling a new queued event until the previous handling has completed.

--
nosy: +Peter.Wentworth

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser k...@shore.net:


--
nosy: +kbk
priority: normal - high

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Gregor Lingl]

Gregor Lingl gregorli...@users.sourceforge.net 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'd like to mention again, that the corresponding script under Python26
does crash also, but with a regular Python Error-Message. It does not
kill IDLE when stated from within IDLE.

So I'd suggest to give this one a higher priority. Should be fixed with 3.2

Regards,
Gregor

--
Added file: http://bugs.python.org/file15149/tkinter_recursionbug_31.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Terry J. Reedy]

Terry J. Reedy tjre...@udel.edu 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 probably due to the same cause, it does act differently:
adding the 'speed(0)' command present in dragbug.py appears to have
fixed the problem with turtlecrash.py.

Rewriting dragbug to use tkinter canvas directly would determine whether
the turtle module is a factor. The change of behavior with turtlecrash
with the speed command suggests to me that it might be.

--
nosy: +tjreedy
Added file: http://bugs.python.org/file15063/turtlecrash.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Gregor Lingl]

New submission from Gregor Lingl gregorli...@users.sourceforge.net:

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:

Running it with Python 3.1 and performing heavy turtle dragging with the
mouse results in:

Fatal Python error: Cannot recover from stack overflow
This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team
-- As I do at the moment ;-) 

Running the same script from Python 2.6: The error is much harder to
reproduce (only with very excessive dragging). It's a bit easier to
reproduce when running the program from a console and  if it occurs one
gets a conventional Python error message:

First a long sequence of:
Exception in Tkinter callback
Traceback (most recent call last):
Exception RuntimeError: 'maximum recursion depth exceeded while  
ignored

Followed by:

Traceback (most recent call last):
  File dragbug.py, line 10, in module
mainloop()
  
  File c:\Python26\lib\traceback.py, line 57, in print_tb
if hasattr(sys, 'tracebacklimit'):
AttributeError: 'module' object has no attribute 'tracebacklimit'

This problem can be overcome by setting a higher recurson limit. But I
think one should require that it doesn't produce a Fatal Error like in
Python 3.1

Regards,
Gregor

--
components: Library (Lib)
files: dragbug.py
messages: 91664
nosy: gregorlingl
severity: normal
status: open
title: Some problem with recursion handling
versions: Python 3.1
Added file: http://bugs.python.org/file14738/dragbug.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[R. David Murray]

R. David Murray rdmur...@bitdance.com 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

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
components: +Tkinter
priority:  - normal
type:  - crash
versions: +Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6717
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com