classification
Title: Crash on deep call stack under Windows
Type: crash Stage:
Components: Interpreter Core, Windows Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: aleReimondo, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2021-08-13 00:17 by aleReimondo, last changed 2021-08-13 21:38 by steve.dower.

Files
File name Uploaded Description Edit
crashWin3.9-2021-08-12.zip aleReimondo, 2021-08-13 00:17 snapshot and test file
Messages (3)
msg399487 - (view) Author: Alejandro Reimondo (aleReimondo) Date: 2021-08-13 00:17
The py8.py file starts a S8 system, a Smalltalk system running on Python runtime, I am actually developing (in Beta).
The system is running w/o problems on OSX systems, but crash (fast exit w/o any information) when running on Windows.
The crash occurs while compiling a simple expression (simple but produce a deep recursion on parsing stage). The expression is shown in "fileMeIn.st".
The issue happens on Windows and python version Python 3.9.2
The stack depth is aprox 1800 frames.
Steps to reproduce the crash:
1.- decompress the zip file in a folder
2.- on command prompt "python -i py8.py"
3.- "Image loaded" must be shown in console
4.- evaluate "t()" to run tests that fileIn the code in "fileMeIn.st"
5.- after aprox. one minute working, the fast exit occurs and the Python VM exits without reporting anything on output
msg399563 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-08-13 21:14
I guess we've got a new path through the interpreter loop that takes more stack space than before and isn't part of our existing recursion tests.

It's probably somewhere in the vector call changes. Capturing the stack at overflow point should show us - I'll see if I can get it easily from the repro.
msg399565 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-08-13 21:38
I get stack overflows all the way back to 3.7, so it's probably not anything new. But our stack overflow detection is clearly not going to catch this case. It's really only set up for a direct call within Python code, but this is going through many more steps.

Best thing you can do as a user is run it with "python -X faulthandler ..." to see the error. Perhaps we can handle the stack overflow ourselves and print a message suggesting that option, but unfortunately this problem doesn't have a generic solution :( The assumption is that you have a known recursion limit for your application, and as a scripting engine, we don't. Decoupling from the C stack is the best hope.
History
Date User Action Args
2021-08-13 21:38:51steve.dowersetmessages: + msg399565
2021-08-13 21:14:39steve.dowersetmessages: + msg399563
components: + Interpreter Core
2021-08-13 00:17:17aleReimondocreate