Update Lib/test/crashers

[JelleZijlstra]

The Lib/test/crashers directory contains some Python files that are known to crash the interpreters. I thought it'd be useful to check in on whether they are still crashing the interpreter.

Here's what I get on a current-ish 3.14 build:

• bogus_code_obj.py: TypeError because we're missing some arguments to the CodeType constructor. I assume this would still crash if you pass the missing args though.
• gc_inspection.py: segfault
• infinite_loop_re.py: takes a long time (this is not exactly a crasher, just a ReDoS)
• mutation_inside_cyclegc.py: no error
• recursive_call.py: hangs for a long time (this sets the recursion limit to a huge value and then does runaway recursion). I believe Mark Shannon's recent interpreter changes make it so this doesn't segfault. Interestingly, I can't kill the process with Ctrl-C, maybe a bug?
• trace_at_recursion_limit.py: RecursionError (which is not a crash)
• underlying_dict.py: segfault

I'll send a PR to make bogus_code_obj.py properly segfault again. Some of the other ones should perhaps be removed.

Linked PRs

• gh-121921: Make bogus_code_obj.py crash the interpreter #121922
• gh-121921: Update Lib/test/crashers #126360

[tomasr8]

recursive_call.py: hangs for a long time (this sets the recursion limit to a huge value and then does runaway recursion). I believe Mark Shannon's recent interpreter changes make it so this doesn't segfault. Interestingly, I can't kill the process with Ctrl-C, maybe a bug?

I am able to kill the process by pressing and holding Ctrl + C for a few seconds which gives me this strange output:

Exception ignored in sys.unraisablehook: <built-in function unraisablehook>
KeyboardInterrupt: 
Traceback (most recent call last):
object address  : 0x70e10bcd1470
object refcount : 3
object type     : 0x5badc2dc6a40
object type name: KeyboardInterrupt
object repr     : KeyboardInterrupt()
lost sys.stderr

As for mutation_inside_cyclegc.py and trace_at_recursion_limit.py, neither of them is segfaulting for me either. Perhaps those two should be removed?

[JelleZijlstra]

As for mutation_inside_cyclegc.py and trace_at_recursion_limit.py, neither of them is segfaulting for me either. Perhaps those two should be removed?

Yes, or converted into unit tests so we don't regress.

[markshannon]

What takes the time in the stack overflow examples is creating the traceback.

If you set the recursion limit to a million, the stack overflow happens quickly, but creating and printing the traceback takes absolutely ages. Hitting Ctrl-C persistently is causing KeyboardInterrupt to be raised in the middle of this, which probably means that the huge overflow traceback gets added to the KeyboardInterrupt as cause or context and that takes forever to create/print. And so on...