Author kj
Recipients BTaskaya, kj, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2021-06-08.09:47:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hi all, I created this issue after discussion in

In issue39573 "[C API] Make PyObject an opaque structure in the limited C API" the commit f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 ("Py_TYPE becomes a static inline function") may have caused test_recursion_in_except_handler to fail only on windows debug builds (according to git bisect anyways) due to higher stack consumption causing a stack overflow.

That test was added in 4e7a69bdb63a104587759d7784124492dcdd496e (Dec 2020), and was passing until last week. Currently another test (bpo-11105, test_ast test_recursion_direct) is masking the broken test, but it's also a stack overflow in windows debug. When I reverted commit f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970, test_recursion_in_except_handler passes but test_recursion_direct still fails.

For test_recursion_direct, the overflow occurs after the Py_Enter/LeaveRecursiveCall guard, when calling some other function like _PyObject_LookupAttr.

I can think of a few possible ways to fix this (in no particular order):

1. Increase stack size for windows builds from 2MB (some valid points against this though, see msg395177).
2. Decrease the global recursion limit only for windows debug.
3. Custom recursion limits for each module depending on OS, which Batuhan has been working on for AST module at GH-26550.
4. Skip the tests on windows debug, since most people on windows use release builds anyways which are unaffected.

Thanks for your time! Which approach would you prefer?
Date User Action Args
2021-06-08 09:47:57kjsetrecipients: + kj, paul.moore, vstinner, tim.golden, zach.ware, steve.dower, pablogsal, BTaskaya
2021-06-08 09:47:57kjsetmessageid: <>
2021-06-08 09:47:57kjlinkissue44348 messages
2021-06-08 09:47:56kjcreate