Following https://docs.python.org/2/c-api/init.html#Py_Finalize, I'm reinitializing embedded python interpreter multiple time in one process.

#include <Python.h>

void f() {
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
      "import datetime\n"
      "print 'Today is',ctime(time())\n");
  Py_Finalize();
}

int main(void) {
  for (int i = 0; i < 30; ++i)
    f();
  return 0;
}

I see 2 sources of memory leaks:

• _once_registry is never teared down.

==20144==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8120 byte(s) in 29 object(s) allocated from:
#0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75
#1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499
#2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521
#3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277
#4 0x62b9a7 in _PyWarnings_Init build/Python-2.7.6/Python/_warnings.c:898
#5 0x4c2985 in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:254
#6 0x4c22a4 in f() build/Python-2.7.6/1.cc:4
#7 0x4c22a4 in main build/Python-2.7.6/1.cc:14

• datetime module creates a bunch of objects in its initialization function and never destroys them

Direct leak of 8120 byte(s) in 29 object(s) allocated from:
#0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75
#1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499
#2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521
#3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277
#4 0x6cb976 in PyErr_NewException build/Python-2.7.6/Python/errors.c:577
#5 0x757227 in initzipimport build/Python-2.7.6/./Modules/zipimport.c:1235
#6 0x6e5797 in init_builtin build/Python-2.7.6/Python/import.c:1999
#7 0x6e158d in load_module build/Python-2.7.6/Python/import.c:1928
#8 0x6e6919 in import_submodule build/Python-2.7.6/Python/import.c:2700
#9 0x6e5ac7 in load_next build/Python-2.7.6/Python/import.c:2515
#10 0x6e036c in import_module_level build/Python-2.7.6/Python/import.c:2224
#11 0x6e036c in PyImport_ImportModuleLevel build/Python-2.7.6/Python/import.c:2288
#12 0x671e6f in builtin___import__ build/Python-2.7.6/Python/bltinmodule.c:49
#13 0x502b40 in PyObject_Call build/Python-2.7.6/Objects/abstract.c:2529
#14 0x502e82 in call_function_tail build/Python-2.7.6/Objects/abstract.c:2561
#15 0x502e82 in PyObject_CallFunction build/Python-2.7.6/Objects/abstract.c:2585
#16 0x6df7b0 in PyImport_Import build/Python-2.7.6/Python/import.c:2886
#17 0x6db9a7 in PyImport_ImportModule build/Python-2.7.6/Python/import.c:2129
#18 0x6db9a7 in _PyImportHooks_Init build/Python-2.7.6/Python/import.c:239
#19 0x4c287f in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:248
#20 0x4c22a4 in f() build/Python-2.7.6/1.cc:4
#21 0x4c22a4 in main build/Python-2.7.6/1.cc:14

Thanks. It would be nice if you could try the same with Python 3.4, or the development version.

Are we fixing these on a case by case basis or is it hopeless (msg146615)?

I think fixing on a case by case is fine.

I've run Evgeniy's example under Valgrind and changed it to import
various C extensions. Unfortunately they all leak more or less, so
perhaps we can revisit this when (if?) the PEP-3121 and PEP-384
changes have been implemented.

For the record, the open issues about applying 3121 and 384 to the standard libary: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=pep+3121&submit=search&status=-1%2C1%2C3

Duplicate of bpo-1635741.