I am embedding the python interpreter in my MFC 
multidocument 
application. In the mainframe class, at creation time, I 
do Py_Initialize(). 
When the program comes to an end, in the mainframe 
destructor, I do 
Py_Finalize(). No Pyobject is created, no 
PyRun_SimpleString is called, 
nothing but the Py_Initialize() and the Py_Finalize() only. 
But those simple 
calls make the program to report leaks, that when are 
breakpointed with 
_CrtSetBreakAlloc (using <crtdbg.h> lib) the 
code "leaked" stops inside 
python code.

I made a new project from scratch (multidocument also), 
without adding no line except 
Py_Initialize and Py_Finalize, an the leak already exists. I 
did a Dialog 
application and used the same calls, and the leak 
already exists. But 
when I make a non MFC application, the leak do not 
exists.

Is this bug a real python bug, or its due an MFC bad 
implementation of 
memory allocation? Please, I need to know if there is a 
way to avoid 
this leaks, because I want to control what leaks are 
really mine (c++), 
what leaks are caused by c++ to python wrapped code, 
and what leaks 
are just python, to have a better control of the 
processes of my 
application.

I am using Python 2.3.3 and VC++ 6.0 with service pack 
5 on a Windows XP Professional with an Athlon XP.

David.

If any information is needed about the leaks and the 
lines that report to be leaked, just tell me and I'll made 
an inform.

Logged In: YES 
user_id=446714

I am seeing the same behavior. The leaks only appear when
the VC++6.0 project is linking to one of the Multithreaded
DLL runtime libraries - which occurs when you use MFC as a
shared DLL. If the project is linking to one of the
Multithreaded non-DLL runtime libraries - which occurs when
you use MFC as a static library, the memory leaks do not appear.

See Roland Trainor's comment.