Update test_crashers

[vstinner]

Feature or enhancement

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Proposal:

test_crashers is currently skipped and some scripts in Lib/test/crashers/ no longer crash.

Linked PRs

• gh-108297: Update test_crashers #108299
• gh-108297: Remove test_crashers #108690
• gh-108297: Update crashers README for test_crashers removal #121475
• [3.13] gh-108297: Update crashers README for test_crashers removal (GH-121475) #121476

[serhiy-storchaka]

Victor, do you remember we measured the recursion limit for different kind of recursion, like via custom __getitem__, __getattr__, __call__, properties, partial(), etc, and you did an awesome work for reducing the stack consumption? Do you remember the issue number? I think that in many of such cases the recursion is still limited, and it would be nice to have tests for this, to avoid regression.

[vstinner]

It was in 2017, search for "Stack consumption" at https://vstinner.github.io/contrib-cpython-2017q1.html

• issue Reduce C stack consumption in function calls #73413: Reduce C stack consumption in function calls
• issue Disable inlining of _PyStack_AsTuple() to reduce the stack consumption #73420: Disable inlining

I added _testcapi.stack_pointer() in issue #75049: see script https://bugs.python.org/file46992/stack_overflow-3.py

On the main branch with a debug build (pydebug with gcc -O0), I get:

test_python_call: 498 calls before crash, stack: 8368 bytes/call
test_python_getitem: 109060 calls before crash, stack: 55 bytes/call
test_python_iterator: 746 calls before crash, stack: 8171 bytes/call

=> total: 110304 calls, 16594 bytes

On the main branch with a release build (gcc -O3), I get:

$ ./python stack_overflow-3.py 
test_python_call: 498 calls before crash, stack: 737 bytes/call
test_python_getitem: 109060 calls before crash, stack: 3 bytes/call
test_python_iterator: 746 calls before crash, stack: 528 bytes/call

=> total: 110304 calls, 1268 bytes

test_python_getitem memory usage is quite good, it's almost free :-)

I'm not sure where 109,060 number comes from.

[serhiy-storchaka]

Thank you Victor. Other issues:

• Fastcall uses more C stack #73044
• Reduce stack consumption of PyObject_CallFunctionObjArgs() and like #73056

where there are more examples of stack overflowing code. I think that they could be included instead of the removed recursive_call.py.

We can also add separate test which runs maximally deep recursion (with the limit depending on platform) to ensure that there is no regression in new versions.

[vstinner]

In this issue, I looked at crasher scripts and some of them no longer crash. They should be removed. I will try to come up with a change to remove them and maybe update the others based on the closed PR #108299.

[vstinner]

Sadly, I failed track of this issue. While it may be nice to cleanup Lib/test/crashers/, it became a lower priority for me since I removed test_crashers, instead of running it. I close the issue. If someone is motivated to cleanup this directory, go ahead and propose a new issue and/or PR.