Issue45645
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2021-10-28 14:12 by pablolob, last changed 2022-04-11 14:59 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
forstack.py | pablolob, 2021-10-28 14:12 |
Messages (6) | |||
---|---|---|---|
msg405185 - (view) | Author: PABLO LOBATO DE LA CRUZ (pablolob) | Date: 2021-10-28 14:12 | |
Deep recursion crashes on Windows (Python 3.9) when the depth limit is increased and no error is shown. Seems to work fine on other systems that I have tried (Linux and MacOS). Please find attached the script to reproduce the error. Expected and other systems output: Calculated N2 Try block finished correctly This is the finally block Output: Calculated N2 |
|||
msg405270 - (view) | Author: Steve Dower (steve.dower) * | Date: 2021-10-28 21:09 | |
This is almost certainly because of how Windows handles stack overflow exceptions, and the fact that there's no way for us to detect it reliably. There's some work going on to reduce the C stack depth when calling heavily nested Python code (see issue45256), but there's nothing else we can really do I'm afraid. I'm marking *this* issue as wontfix, but hopefully we can make some improvement on this general issue through other issues. Thanks for reporting it! |
|||
msg405279 - (view) | Author: PABLO LOBATO DE LA CRUZ (pablolob) | Date: 2021-10-28 21:59 | |
I see thanks for answering so quickly. But why does it happen only on Windows? El jue, 28 oct 2021 a las 23:09, Steve Dower (<report@bugs.python.org>) escribió: > > Steve Dower <steve.dower@python.org> added the comment: > > This is almost certainly because of how Windows handles stack overflow > exceptions, and the fact that there's no way for us to detect it reliably. > > There's some work going on to reduce the C stack depth when calling > heavily nested Python code (see issue45256), but there's nothing else we > can really do I'm afraid. > > I'm marking *this* issue as wontfix, but hopefully we can make some > improvement on this general issue through other issues. Thanks for > reporting it! > > ---------- > resolution: -> wont fix > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue45645> > _______________________________________ > |
|||
msg405282 - (view) | Author: Steve Dower (steve.dower) * | Date: 2021-10-28 22:28 | |
> But why does it happen only on Windows? Because it's the operating system that is terminating the process :) Other operating systems behave differently when you exceed the stack, and may also allocate different amounts of stack space, making it less likely that you hit it. |
|||
msg405294 - (view) | Author: PABLO LOBATO DE LA CRUZ (pablolob) | Date: 2021-10-29 09:03 | |
I see. Thank you very much Steve :) El vie, 29 oct 2021 a las 0:29, Steve Dower (<report@bugs.python.org>) escribió: > > Steve Dower <steve.dower@python.org> added the comment: > > > But why does it happen only on Windows? > > Because it's the operating system that is terminating the process :) > Other operating systems behave differently when you exceed the stack, > and may also allocate different amounts of stack space, making it less > likely that you hit it. > > ---------- > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue45645> > _______________________________________ > |
|||
msg405333 - (view) | Author: Eryk Sun (eryksun) * | Date: 2021-10-29 20:12 | |
In theory, a crash could be prevented in most cases by setting a larger stack guarantee (i.e. region of guard pages) via SetThreadStackGuarantee() [1] and using a vectored exception handler [2]. The exception handler can set a flag in the thread state that indicates stack-overflow recovery is in progress and then return EXCEPTION_CONTINUE_EXECUTION. The guaranteed stack space will be available, but there are no guard pages, so another stack overflow in this context will crash with an access violation. The stack guarantee should be large enough to raise and unwind a RecursionError. As the stack unwinds, if the recovery flag is still set, try calling _resetstkoflw() [3] to restore the guard region. If it succeeds, clear the flag in the thread state. For giggles, here's a toy example using ctypes: import ctypes import sys kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) ucrt = ctypes.CDLL('ucrtbase', use_errno=True) EXCEPTION_CONTINUE_EXECUTION = 0xFFFFFFFF stack_overflow = False @ctypes.WINFUNCTYPE(ctypes.c_long, ctypes.c_void_p) def handler(p): global stack_overflow stack_overflow = True return EXCEPTION_CONTINUE_EXECUTION kernel32.AddVectoredExceptionHandler(1, handler) def recursive(): if stack_overflow: raise RecursionError recursive() # Normally the stack has 2 or 3 guard pages, which is actually # enough to recover in this example, but let's increase it to # 9 pages (8 plus an extra that the memory manager adds). You # can inspect this with Sysinternals VMMap. size = ctypes.c_ulong(8 * 4096) kernel32.SetThreadStackGuarantee(ctypes.byref(size)) sys.setrecursionlimit(1000000) for n in range(5): try: recursive() except RecursionError: if stack_overflow and ucrt._resetstkoflw(): stack_overflow = False print("recovered from stack overflow:", n) --- [1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadstackguarantee [2] https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-addvectoredexceptionhandler [3] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/resetstkoflw?view=msvc-160 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:59:51 | admin | set | github: 89808 |
2021-10-29 20:12:22 | eryksun | set | nosy:
+ eryksun messages: + msg405333 |
2021-10-29 09:03:47 | pablolob | set | messages: + msg405294 |
2021-10-28 22:28:25 | steve.dower | set | messages: + msg405282 |
2021-10-28 21:59:19 | pablolob | set | messages: + msg405279 |
2021-10-28 21:09:34 | steve.dower | set | status: open -> closed resolution: wont fix messages: + msg405270 stage: resolved |
2021-10-28 14:12:52 | pablolob | create |