Issue 8368: Memory leak on multi-threaded PyObject_CallObject (original) (raw)

Created on 2010-04-11 13:32 by Krauzi, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue8368.tgz loewis,2010-04-11 17:31
Python Bug.zip loewis,2010-04-11 20:02
Messages (10)
msg102832 - (view) Author: Krauzi (Krauzi) Date: 2010-04-11 13:32
Hi guys, i think this is a bug and Matt from help@python.org suggested me to report it here: I attached a sample project where the memory leak occurs.I created a sample project where the memory leak occurs. It's a visual studio 2008 project and uses windows threads so you have to recompile when using linux (makefile not included). 500 thread calls result in a memory leak of about 1 MB.
msg102839 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-11 14:52
Why do you think PyObject_CallObject() is the culprit? There could be any number of reasons for a memory leak: - cyclic references needing to be cleared (have you tried calling PyGC_Collect()?) - reference leak(s) in your own internal logic - inefficiencies in the Windows memory allocator which mean "freed" memory is not necessarily reclaimed PyObject_CallObject() itself is called with the GIL held, so the multithreaded nature of the program shouldn't be a factor. I would also suggest running more iterations, to see whether memory consumption reaches a stable state or grows endlessly.
msg102846 - (view) Author: Krauzi (Krauzi) Date: 2010-04-11 15:23
i think the PyObject_Call* is the problem because when i comment it out, i do not longer get leaks. The arguments are also correctly decremented because i also can use NULL as argument and i get the same mem leaks like before.
msg102855 - (view) Author: Krauzi (Krauzi) Date: 2010-04-11 17:17
kay updated the code. Please use this: http://paste.pocoo.org/show/200484/ smaller code but problem still the same.
msg102856 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-04-11 17:31
I've ported the program to Linux (see attached tar file). I cannot observe any memory leak here - even if I let the program run for a long time (linking with Python 2.6). Memory usage in top goes up and down, but never over some upper limit. The only changes to the source that I made are these: - remove the pause calls - run the thread creation in an infinite loop - join the threads I notice that the Win32 version also doesn't join the threads. Notice that this is a memory leak in itself.
msg102870 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-11 19:16
Thanks Martin. I see no leak here either (Linux with Python 2.6 and 2.7).
msg102871 - (view) Author: Krauzi (Krauzi) Date: 2010-04-11 19:23
oh no then it's a windows bug. Now i understand why many devs use linux instead of windows......
msg102879 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-04-11 20:02
I can't reproduce the problem on Windows, either. The attached project runs the thread creation in a loop (leaving the 3s sleep in the code). I see (in process viewer) that the Commit Size varies between 13MB and 14MB; there is no indication of a leak.
msg102883 - (view) Author: Krauzi (Krauzi) Date: 2010-04-11 20:38
ah no you misunderstood me. Please add a system("pause") and a system("pause") at the beginning of the while(1)-loop and one at the end. Then compare the memory usage of the program at the beginning (lets say it's 2,6 MB) with the usage at the second pause. In may case its 3,9 MB at this point. THIS is what i mean with the leak. On my computer on about 30000-35000 calls i pass the 4 MB "border".
msg102899 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-04-11 22:00
Ok, it consumes more memory - why do you think there is a leak?
History
Date User Action Args
2022-04-11 14:56:59 admin set github: 52615
2010-04-11 22:00:36 loewis set messages: +
2010-04-11 20:38:43 Krauzi set messages: +
2010-04-11 20:02:49 loewis set status: open -> closedfiles: + Python Bug.zipresolution: not a bugmessages: +
2010-04-11 19:23:03 Krauzi set messages: +
2010-04-11 19:16:39 pitrou set messages: +
2010-04-11 17:31:56 loewis set files: + issue8368.tgznosy: + loewismessages: +
2010-04-11 17🔞13 Krauzi set files: - Python Bug.zip
2010-04-11 17:17:58 Krauzi set messages: +
2010-04-11 15:23:54 Krauzi set messages: +
2010-04-11 14:52:45 pitrou set nosy: + pitroumessages: +
2010-04-11 13:32:13 Krauzi create