`Py_Initialize()` still leaks in libpython3.11

Bug Report

The following code leaks several hundred kilobytes with the latest libpython from the Ubuntu APT repository:

#include <Python.h>

int main(void) {
        Py_Initialize();
        Py_Finalize();
        return 0;
}

With libpython3.10, it consistently leaks 480 KB, whereas with libpython3.11, it consistently leaks 408 KB. (These are proper IEC power-of-10 kilobytes, not power-of-2 kibibytes.) I’ve verified this by running this code as a Clang-compiled dynamic executable through Valgrind.

Binary Images

libpython3.10 version:

linux-vdso.so.1 (0x0000ffffbf695000)
libpython3.10.so.1.0 => /lib/aarch64-linux-gnu/libpython3.10.so.1.0 (0x0000ffffbf050000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffbeea0000)
libexpat.so.1 => /lib/aarch64-linux-gnu/libexpat.so.1 (0x0000ffffbee60000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffffbee30000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffbed90000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffbf65c000)

libpython3.11 version:

linux-vdso.so.1 (0x0000ffffaee59000)
libpython3.11.so.1.0 => /lib/aarch64-linux-gnu/libpython3.11.so.1.0 (0x0000ffffae650000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffae4a0000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffae400000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffffae3d0000)
libexpat.so.1 => /lib/aarch64-linux-gnu/libexpat.so.1 (0x0000ffffae390000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffaee20000)

Valgrind Reports

• libpython3.10.log
• libpython3.11.log

Environment

• CPython versions tested on:
  • libpython3.10
  • libpython3.11
    (Both from the Ubuntu APT repository)
• Operating system and architecture:
  • Ubuntu 22.04.1 LTS
  • AArch64
  • Virtual machine on top of Apple’s Virtualization and Hypervisor frameworks
  • macOS Ventura 13.2 (a) Beta (22D7750270d)
  • MacBook Pro with M1 Max

Start by running the standalone C program with Py_Initialize() and Py_Finalize() under Valgrind, using the Ubuntu AArch64 libpython3.10 and libpython3.11 versions described in the report. Compare the resulting reports with the linked Valgrind logs to determine the source and expected status of the allocations; done means the leak is explained and the behavior is corrected or documented.