[issue32026] Memory leaks in Python on Windows

2017-11-14 Thread PJ Naughter

New submission from PJ Naughter :

I would like to report memory leaks in Python 3.6.3 when embedded in a C++ 
Windows app. I have download the Python 3.6.3 code and compiled a debug version 
of Python with my copy of Visual Studio 2017 Professional (have also confirmed 
the problem in Visual Studio 2015 Professional) and built the debug version of 
the Python DLL. With the following sample app I get memory leaks when compiled 
in debug mode:


//Pull in the Windows header and the MSVC Debug C Runtime
#include 
#define _CRTDBG_MAP_ALLOC
#include 
#include 

//Pull in Python
#include  

int __stdcall WinMain(HINSTANCE /*hInstance*/, HINSTANCE /*hPrevInstance*/, 
_In_ LPTSTR /*lpCmdLine*/, int /*nCmdShow*/)
{
  //Track memory leaks using the MSVC Debug CRT
  _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
  //_CrtSetBreakAlloc(81);

  //Initialize Python
  Py_Initialize();
  PyEval_InitThreads();

  //Pretend this app does something!
  Sleep(2000);

  //Shutdown Python
  Py_FinalizeEx();
}

Taking out the calls to Py_Initialize, PyEval_InitThreads & Py_FinalizeEx 
results in no memory leaks being reported. The actual reported memory leaks are 
reported to the output window in Visual Studio as follows:

Detected memory leaks!
Dumping objects ->
{700} normal block at 0x014E0078, 2604 bytes long.
Data: <r   o   > 00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 698 } normal block at 0x01502148, 2604 bytes long.
Data : <r   o   > 00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 697 } normal block at 0x014DA350, 52 bytes long.
Data : <   $r   > 00 00 00 24 72 FB FB FB FF FF FF FF FF FF FF FF
{ 458 } normal block at 0x01511A88, 81968 bytes long.
Data : <  @ r @ o   > 00 01 40 20 72 FB FB FB 00 01 40 10 6F FB FB FB
{ 389 } normal block at 0x014F1270, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 359 } normal block at 0x014FA730, 5168 bytes long.
Data : <r   o   > 00 00 14 20 72 FB FB FB 00 00 14 10 6F FB FB FB
{ 319 } normal block at 0x014EE120, 2604 bytes long.
Data : <r   o   > 00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 315 } normal block at 0x014EC478, 1200 bytes long.
Data : <r   o   > 00 00 04 A0 72 FB FB FB 00 00 04 90 6F FB FB FB
{ 307 } normal block at 0x01500B98, 529 bytes long.
Data : <r   o   > 00 00 02 01 72 FB FB FB 00 00 01 F1 6F FB FB FB
{ 281 } normal block at 0x01500350, 709 bytes long.
Data : <r   o   > 00 00 02 B5 72 FB FB FB 00 00 02 A5 6F FB FB FB
{ 264 } normal block at 0x014FDAF8, 10284 bytes long.
Data : <  (r(o   > 00 00 28 1C 72 FB FB FB 00 00 28 0C 6F FB FB FB
{ 253 } normal block at 0x014F89F0, 539 bytes long.
Data : <r   o   > 00 00 02 0B 72 FB FB FB 00 00 01 FB 6F FB FB FB
{ 248 } normal block at 0x014F5448, 847 bytes long.
Data: < ? r / o   > 00 00 03 3F 72 FB FB FB 00 00 03 2F 6F FB FB FB
{ 247 } normal block at 0x014F0A78, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 235 } normal block at 0x014F2A58, 1409 bytes long.
Data : <   qr  ao   > 00 00 05 71 72 FB FB FB 00 00 05 61 6F FB FB FB
{ 234 } normal block at 0x014F1FB8, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 233 } normal block at 0x014F1A68, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 232 } normal block at 0x014F1518, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 231 } normal block at 0x014E2BE0, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 230 } normal block at 0x014EFFF8, 2604 bytes long.
Data : <r   o   > 00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 229 } normal block at 0x014EFD60, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 228 } normal block at 0x014EF9E8, 843 bytes long.
Data : <; r + o   > 00 00 03 3B 72 FB FB FB 00 00 03 2B 6F FB FB FB
{ 227 } normal block at 0x014EF750, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 226 } normal block at 0x014E4410, 561 bytes long.
Data : <   !r   o   > 00 00 02 21 72 FB FB FB 00 00 02 11 6F FB FB FB
{ 225 } normal block at 0x014EF1D0, 1360 bytes long.
Data : <   @r  0o   > 00 00 05 40 72 FB FB FB 00 00 05 30 6F FB FB FB
{ 224 } normal block at 0x014E49E0, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 206 } normal block at 0x014E3C88, 1200 bytes long.
Data : <r   o   > 00 00 04 A0 72 FB FB FB 00 00 04 90 6F FB FB FB
{ 205 } normal block at 0x014E3978, 734 bytes long.
Data : <r   o   > 00 00 02 CE 72 FB FB FB 00 00 02 BE 6F FB FB FB
{ 204 } normal block at 0x

[issue32026] Memory leaks in Python on Windows

2017-11-14 Thread PJ Naughter

PJ Naughter  added the comment:

OK, Thanks for the quick reply. I have just migrated my application from Python 
3.3 to Python 3.6.3 and would not expect you to backport changes from the 3.7 
development stream to the released stream. What I will do when I get a chance 
is pull down the 3.7 sources and compare the demo app I have produced with 3.7 
vs 3.6.3 to see if improvements have been done in this area.

--

___
Python tracker 
<https://bugs.python.org/issue32026>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com