Update test_crashers

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

pythongh-108297: Update test_crashers

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.

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.

pythongh-108297: Update test_crashers

Thank you Victor. Other issues:

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.

pythongh-108297: Remove test_crashers

gh-108297: Remove test_crashers (#108690)

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.

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.

gh-108297: Update crashers README for test_crashers removal (#121475)

pythongh-108297: Update crashers README for test_crashers removal (py…

[3.13] gh-108297: Update crashers README for test_crashers removal (#…

pythongh-108297: Update crashers README for test_crashers removal (py…

Navigation Menu

Repository navigation

Update test_crashers #108297

Feature or enhancement

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Proposal:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Update test_crashers #108297

Description

Feature or enhancement

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Proposal:

Linked PRs

Activity

serhiy-storchaka commented on Aug 22, 2023

vstinner commented on Aug 22, 2023

serhiy-storchaka commented on Aug 23, 2023

vstinner commented on Aug 30, 2023

vstinner commented on Sep 13, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions