[issue27734] Memory leaks at Python35-32

[R. David Murray]

Changes by R. David Murray :


--
superseder:  -> PEP 3121, 384 Refactoring

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Stefan Krah]

Stefan Krah added the comment:

#15787. All Python versions have these leaks, which aren't terribly important 
in practice.

If it still bothers you, consider writing a Python C extension instead of 
"embedding" Python, which is what most people do anyway.

--
status: open -> closed

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Филипп Пономарев added the comment:

And one more thing.
Is there python version exist without leaks? 
Or all of them have those leaks?
thank you!

--

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Филипп Пономарев added the comment:

I understand and totally agree, but if u're working on it, can u give me a 
reference to open issue, or should I use Stefan link?
I should report to my сhief :)
After that you can close it immideatly.

--
status: closed -> open

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[R. David Murray]

R. David Murray added the comment:

Филипп: As Stefan said, we know there are problems with initialize/finalize, 
but the problems are deep and the project to correct them is ongoing.  So, this 
is an example of an already identified leak that we are working on, and 
consequently I'll close this issue.  (If you disagree with Stefan's diagnosis, 
please let us know with supporting info about why.)

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Stefan Krah]

Stefan Krah added the comment:

It is a known problem that PEP 3121 and later similar PEPs address.
Most C extensions leak a (usually very small) amount of memory with
each call to Initialize()/Finalize().

IMO this issue can be closed.

--
nosy: +skrah

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Филипп Пономарев added the comment:

I've exported it in source.def - tstf @1 *
thank you*

Sorry for my english =)

--

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

New submission from Филипп Пономарев:

I've created Win32 app (MFC+ATL)
Added includes, added \python35_d.lib

runed main.cpp:
int main()
{
int nRetCode = 0;

HMODULE hModule = ::GetModuleHandle(nullptr);

if (hModule != nullptr)
{
// initialize MFC and print and error on failure
if (!AfxWinInit(hModule, nullptr, ::GetCommandLine(), 0))
{
// TODO: change error code to suit your needs
wprintf(L"Fatal Error: MFC initialization failed\n");
nRetCode = 1;
}
else
{
Py_Initialize();
Py_Finalize();
return 0;
}
}
else
{
// TODO: change error code to suit your needs
wprintf(L"Fatal Error: GetModuleHandle failed\n");
nRetCode = 1;
}

return nRetCode;
}


get leaks:
The thread 0x105c has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
{4888} normal block at 0x003ADE28, 6176 bytes long.
 Data:  00 00 18 10 6D FB FB FB 01 00 00 00 00 02 00 00 
{4879} normal block at 0x003FFF28, 3104 bytes long.
 Data:  00 00 0C 10 6D FB FB FB 01 00 00 00 00 01 00 00 
{4747} normal block at 0x003F7CC0, 80 bytes long.
 Data: <   @m   x   > 00 00 00 40 6D FB FB FB 78 F7 91 00 00 00 00 00 
{4742} normal block at 0x003FC240, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4734} normal block at 0x003EE398, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4732} normal block at 0x003FC1C0, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4731} normal block at 0x003EE2E8, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4723} normal block at 0x003EE238, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4721} normal block at 0x003F86F8, 416 bytes long.
 Data:  00 00 01 90 6D FB FB FB 01 00 00 00 20 00 00 00 
{4720} normal block at 0x003FC140, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4713} normal block at 0x003EE188, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4711} normal block at 0x003FC0C0, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4710} normal block at 0x003F6A30, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{4703} normal block at 0x003EE0D8, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4701} normal block at 0x003FC040, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4694} normal block at 0x003EE028, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{4642} normal block at 0x003FBFC0, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 00 
{4635} normal block at 0x003EDEC8, 128 bytes long.
 Data: <   pm   > 00 00 00 70 6D FB FB FB 01 00 00 00 08 00 00 00 
{3981} normal block at 0x003F5680, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3973} normal block at 0x003F5568, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3971} normal block at 0x003F5450, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3957} normal block at 0x003F5338, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3949} normal block at 0x003F5220, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3940} normal block at 0x003F5108, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3938} normal block at 0x003F4FF0, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3930} normal block at 0x003F4ED8, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3922} normal block at 0x003F4DC0, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3908} normal block at 0x003A2700, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3900} normal block at 0x003A24D0, 224 bytes long.
 Data:  00 00 00 D0 6D FB FB FB 01 00 00 00 10 00 00 00 
{3383} normal block at 0x003ABBD8, 80 bytes long.
 Data: <   @mP1 > 00 00 00 40 6D FB FB FB B8 50 31 00 00 00 00 00 
{3379} normal block at 0x003C9338, 800 bytes long.
 Data:  00 00 03 10 6D FB FB FB 01 00 00 00 40 00 00 00 
{3368} normal block at 0x003D9BB0, 80 bytes long.
 Data: <   @m   > 00 00 00 40 6D FB FB FB 01 00 00 00 04 00 00 

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Филипп Пономарев added the comment:

Hmm. Correct me if I'm not right.
You agree that you have leaks, but you will not do anything with them until 
they start repeat in a loop? So I've updated problem.

Thnx about nosy, idk.

What I want is to use Python API without leaks in my programm.

The problem is here:
1. I've created test.dll, which is static linked with Python. I've function 
tstf there:
void tstf()
{
Py_Initialize();
Py_Finalize();
}
(ofcourse I've imported it in source.def - tstf @1)

And I have main dll:

typedef void(*vv)();
void exec()
{
HMODULE hModule = ::LoadLibrary(L"d:\\PATH_TO_TEST.dll");
vv fnc = (vv)::GetProcAddress(hModule, "tstf");
(*fnc)();
::FreeLibrary(hModule);
}

int main
{
exec();
//exec();
//exec();
}

So I get more leaks because of more call exec() function.

Waiting for your answer, than you!

--

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Zachary Ware]

Zachary Ware added the comment:

Please don't remove yourself from the nosy list, we need your input to figure 
out exactly what may need to be fixed.

--
nosy: +Филипп Пономарев

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Changes by Филипп Пономарев :


--
components: +Windows -2to3 (2.x to 3.x conversion tool)
nosy: +paul.moore, steve.dower, tim.golden, zach.ware -Филипп Пономарев
type:  -> resource usage

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Филипп Пономарев]

Changes by Филипп Пономарев :


--
components: 2to3 (2.x to 3.x conversion tool)
nosy: Филипп Пономарев
priority: normal
severity: normal
status: open
title: Memory leaks at Python35-32
versions: Python 3.5

___
Python tracker 

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