tests: run pytest under Python devmode

[XuehaiPan]

Description

See also: https://docs.python.org/3/library/devmode.html

The Python devmode can be enabled via:

python3 -X dev ...

or

PYTHONDEVMODE=1 python3 ...

Suggested changelog entry:

• run pytest under Python devmode

[XuehaiPan]

Alright, the flaky test previously found in #5706 is caused by enabling more Python tracing.

[XuehaiPan]

NB: reusable workflows will not inherit env from the caller workflow.

[XuehaiPan]

Wait for Python 3.14.0b3 release for:

• Regression in 3.14: setting __dict__ on custom type broken (mypyc, pybind11) python/cpython#133912
• GH-133912: Fix PyObject_GenericSetDict to handle inline values python/cpython#134725

to resolve the segmentation faults in tests.

[Skylion007]

Interesting, why does it segfault under devmode? Is this indicative of a serious error I wonder?

[XuehaiPan]

why does it segfault under devmode?

From the devmode docs: https://docs.python.org/3/library/devmode.html

Install debug hooks on memory allocators to check for:

• Buffer underflow
• Buffer overflow
• Memory allocator API violation
• Unsafe usage of the GIL

See the PyMem_SetupDebugHooks() C function.

It behaves as if the PYTHONMALLOC environment variable is set to debug.

To enable the Python Development Mode without installing debug hooks on memory allocators, set the PYTHONMALLOC environment variable to default.

[henryiii]

I can verify that it still segfaults on the latest 3.14t (https://github.com/python/cpython/tree/5b39741a0952624ed31dfe312ad32b067353ea7b), so 3.14b3 won't fix it.

[henryiii]

Ohh, interesting, if I swap xfail for skipif, then it passes. So it's messing up the state and the fix doesn't seem to be working. Shouldn't it be xpassing with current 3.14 branch build?

[henryiii]

Ahh, no, I take it back, I did a proper rebuild and the latest 3.14t does work without segfault in dev mode. So yes, this is just a leftover from this bug.

[henryiii]

I think we need to drop the gc tests on free-threaded Python. Unless there's some way to guarantee a stop-the-world event occurs, but I believe the general option is "never rely on the gc to remove anything at some time".

[rwgk]

I think we need to drop the gc tests on free-threaded Python.

Yes.

[henryiii]

Thanks!