main
main copied to clipboard
IronLanguages
StackOverflow with continue from try..except
We are running IronPython 2.7.3. We have been getting a StackOverflow error, which we have reduced to the attached program. It only crashes when run under ipy64, without -X:Debug.
The crash is very easy to make go away, with seemingly innocuous modifications to the program, and different builds of IronPython 2.7.3 (e.g. a debug build) produce different behavior and the program will need some modification in order to exhibit the crash. I have never seen the problem with ipy.exe, only with ipy64.exe.
But if I put this program, excon1.py, in my C:\Program Files (x86)\IronPython
2.7 folder, start a command prompt in that folder and type
ipy64 excon1.py
I see...
Process is terminated due to StackOverflowException.
It doesn't go very far before overflowing the stack. On my machine I can reduce the range(1000) to range(50) and still see the crash.
===excon1.py===
def f(j):
raise Exception("test")
for j in range(1000):
try:
f(j)
except:
continue
print "finished"
Work Item Details
Original CodePlex Issue: Issue 34186 Status: Proposed Reason Closed: Unassigned Assigned to: Unassigned Reported on: Jun 20, 2013 at 10:17 PM Reported by: shacktoms Updated on: Jun 25, 2013 at 10:31 PM Updated by: shacktoms
Plaintext Attachments
CodePlex Issue #34186 Plain Text Attachments
On 2013-06-26 05:31:39 UTC, shacktoms commented:
I did some poking around and found that the problem seems to be this. The generated code for an except clause includes a "LeaveExceptionHandler" instruction. The code for the "continue" appears to create a branch that skips this instruction. The result is that Interpreter.HandleException never returns to Interpreter.Run, but instead continues to execute the frame within its loop. Then, on the next iteration, the raised Python exception causes Interpreter.HandleException to call itself recursively. The stack thus fills with recursive calls to Interpreter.HandleException.
I also found that this problem also exists in ipy.exe, perhaps I didn't see it earlier because its stack is effectively deeper (maybe this is because the stack frames are smaller).
Because I thought the problem might arise from the "goto nature" of "continue", and exception handling might be different, I tried a workaround using an exception handling equivalent to the "continue" statement. That is in excon3.py. However, this didn't work, so it appears the problem is more pervasive than just "continue". A workaround using a flag, placing the continue outside the except, did work.
===excon3.py=== class Continue(Exception): pass
def f(j): raise Exception("test")
for j in range(1000): try: try: f(j) except: raise Continue() except Continue: pass
print "finished"
