Dedicated tests for subinterpreter support and reference leaks

Core Development
1

This is a follow up on Extension modules with static types and Python embedding and subinterpreters.

As of 3.12 current main, most of the extension modules are already ported to multiphase initialization / heap types as per PEP 687 – Isolating modules in the standard library | peps.python.org and remaining are work in progress like elementree (Thanks! @erlendaasland). This has fixed some old reference / memory leaks and subinterpreter related bugs as expected, however we don’t have dedicated tests for subinterpreter support and if we are not cautious it is possible to reintroduce such bugs and our test suite won’t catch those.

I would like to seek consensus on this and I propose to add dedicated tests for these.

  • Add a command line option to python to check at runtime exit that there are no reference leaks and each module which is already ported will be checked for reference leak in a dedicated isolated subprocess by importing it. Subprocess is necessary to maintain isolation between modules otherwise it will be a chaos to debug.

  • Add tests when modules are imported in multiple sub interpreters to expose races and memory leaks caused by bugs in caching or globals. This is simpler as we already have infrastructure for running code in subinterpreters.

Some modules which are ported but import other not ported modules cannot be tested right now but as we are porting more of these, eventually all modules will be ported and all can be tested.

Other ideas to better test this are welcome.

cc @erlendaasland @eric.snow

3 Likes
2

Big +1 for this. Do you have an idea of how this test infrastructure should look?

3

It sounds like test_embed, so presumably much like that infrastructure (hopefully the same one, but that set of tests is pretty big and complex already).