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

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.

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.