In the attached program, the total memory consumption of the process, goes up each time a new subinterpreter imports a bunch of modules. When the subinterpreter is shutdown with Py_EndInterpreter, the memory consumed with import of modules is not returned back. Hence the amount of memory consumed keeps increasing with each loop. It goes up from about 8MB to about 11MB after few loops. Strangely it doesn't rise any further.

I have tested this only for Python 2.6.5

Is this the same as #222684?

No. This is not the same as #222684?

Indeed, the code looks similar, but #222684 seems to be fixed, and doesn't use PyImport_ImportModule, so maybe the leak is there.

As a first guess, I would suspect that this is just badly fragmenting the heap and we aren't freeing up any arenas to pass back to the OS.

The fact that the "leak" doesn't grow seems to confirm Nick supposition.

Close as invalid?

Most builtin modules keep static references to common objects: exceptions, types, &co.  These references are currently never freed, but are reused by all sub-interpreters.
It the memory usage stays stable, even after many calls to Py_NewInterpreter()/Py_EndInterpreter(), this is not a bug!

Please don't add everyone in existence to the nosy list.

I think this is a non-issue. Closing.

If you have a testcase proving real leaks in a current release, reopen.

Sorry about the previous report. I should have tested it thoroughly. Yes, it does not seem to rise but eventually it does. This time, I'v added garbage collection right after the subinterpreter is shutdown. The memory consumption does not seem to rise above 8MB when you start the test. But if you leave it running for couple of hours I have seen it grown upto 24MB. I haven't tested more that that but it seems that if you run it for couple of days, memory consumption will grow upto few 100 MB.
This is strange because mod_python doesn't seem to be doing anything special to handle this, then how does it work with mod_python?

a) Python 2.6 is open only for security fixes. Could you possibly try in 2.7, 3.1 and 3.2?

b) Could you run the test a bit longer and confirm that the leak is slowly growing?

c) I assume your mod_python is running under Apache. Apache restarts processes after X requests are served, so any (slow growing) leak would be not aparent.

Thanks for your effort.

I wouldn't use mod_python as any guide for how to use sub interpreters as its usage of sub interpreters and threading in conjunction with them is technically broken, not following properly the Python C API requirements. It doesn't even shutdown the Python interpreters properly resulting in memory leaks on Apache restarts into the Apache parent process which is then inherited by all forked Apache child processes.

Also, mod_python does not destroy sub interpreters within the life of the process and then create replacements. It is a bit of a misconception that some have that mod_python creates a new sub interpreter for each request, it doesn't. Instead once a sub interpreter is created it persists for the life of the process. Thus it doesn't even trigger the scenario you talk about.

In early versions of mod_wsgi the recycling of sub interpreters within the lifetime of the process was tried but was found not to be practical and feature was removed. The big stumbling block was third party C extensions. Various C extensions do not cope well with being initialised within context of one sub interpreter, with the sub interpreter being destroyed, and the C extension then being used in context of another sub interpreter. This usage pattern caused memory leaks in some cases and in worst case the process would crash.

In short, use of sub interpreters for short periods of time and then destroying them is all but unusable except within very constrained situations where no use is made of complex C extensions.

For related information see:

http://blog.dscpl.com.au/2009/03/python-interpreter-is-not-created-for.html
http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html

Swapnil, please pay attention to what people write.
PYTHON 2.6 IS NOT OPEN FOR BUGFIXES.
Please do not add 2.6 to this issue again or reopen until you find a problem with 2.7.1 or 3.2.0.