STINNER Victor <vstin...@python.org> added the comment:
I confirm that I'm able to reproduce the issue on the master branch: $ PYTHONMALLOC=malloc valgrind --leak-check=full --log-file=valgrind.log --num-callers=20 ./python -c pass ==44052== 32 bytes in 1 blocks are definitely lost in loss record 187 of 2,264 ==44052== at 0x483980B: malloc (vg_replace_malloc.c:309) ==44052== by 0x46DA1E: _PyMem_RawMalloc (obmalloc.c:99) ==44052== by 0x46EBE1: PyMem_RawMalloc (obmalloc.c:572) ==44052== by 0x5475C7: PyThread_allocate_lock (thread_pthread.h:379) ==44052== by 0x4ED6EF: _PyEval_InitThreads (ceval.c:296) ==44052== by 0x52FE87: pycore_create_interpreter (pylifecycle.c:561) ==44052== by 0x5316B3: pyinit_config (pylifecycle.c:757) ==44052== by 0x532D38: pyinit_core (pylifecycle.c:924) ==44052== by 0x5338F5: Py_InitializeFromConfig (pylifecycle.c:1134) ==44052== by 0x41DA88: pymain_init (main.c:66) ==44052== by 0x41EAAC: pymain_main (main.c:653) ==44052== by 0x41EB39: Py_BytesMain (main.c:686) ==44052== by 0x41D6CE: main (python.c:16) > 50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a leak. Possibly the leak was there before but showed up under "still reachable". Python freed pending calls at exit. It's just that Valgrind decided to complain about them :-) => Attached PR fix the issue. Note: the GIL is still leaked at exit. See "Don't destroy the GIL at exit" section of https://vstinner.github.io/daemon-threads-python-finalization-python32.html for the rationale. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40226> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com