get_memory_info() Leaks Handles

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run get_memory_info() in a loop

What is the expected output? What do you see instead?

Handles should not increase.

What version of psutil are you using? What Python version?

Python 2.5
psutil 0.2.1 (From download package)

On what operating system? Is it 32bit or 64bit version?

Windows XP 32-bit

Please provide any additional information below.

It seems as though the opened handle in _psutil_mswindows.c:465 never gets 
closed after being used. In other parts of the source the appropriate 
CloseHandle function destroys the handle returned from OpenProcess. In my 
script this causes a lot of problems due to the constant access to 
get_memory_info() and run time.

Original issue reported on code.google.com by codyrpie...@gmail.com on 26 May 2011 at 5:30

[GoogleCodeExporter]

Thanks for the issue report, get_memory_info() was indeed not closing the 
handles opened. Fixed in r977

Original comment by jlo...@gmail.com on 26 May 2011 at 5:42

• Changed state: FixedInSVN

[GoogleCodeExporter]

Original comment by jlo...@gmail.com on 26 May 2011 at 5:42

• Added labels: OpSys-Windows

[GoogleCodeExporter]

Original comment by jlo...@gmail.com on 26 May 2011 at 5:42

• Added labels: Milestone-0.2.2

[GoogleCodeExporter]

I noticed there are at least a couple more places where CloseHandle() should be 
called.
I think it would be good to have a test for this (it's not the first report).
Maybe it would make sense to expose a method to determine opened handles on 
Windows.
Not sure whether public or private; is it something that might be desirable?

Original comment by g.rodola on 26 May 2011 at 6:55

• Changed state: ReOpened

[GoogleCodeExporter]

Fine with me if we add a test for it, but I thought we already had memory leak 
testing that should have caught these?

Original comment by jlo...@gmail.com on 26 May 2011 at 6:57

[GoogleCodeExporter]

Handles do not appear as memory usage for a process.

Original comment by wj32...@gmail.com on 27 May 2011 at 8:40

[GoogleCodeExporter]

See r979 and r980.
It seems we are leaking handles somewhere in get_process_ppid().

Original comment by g.rodola on 31 May 2011 at 12:13

• Changed state: Started

[GoogleCodeExporter]

Original comment by g.rodola on 27 Jun 2011 at 5:52

• Added labels: Milestone-0.3.0

[GoogleCodeExporter]

The failures were false positives.
Closing this out as fixed.

Original comment by g.rodola on 30 Jun 2011 at 10:22

• Changed state: FixedInSVN

[GoogleCodeExporter]

Original comment by g.rodola on 8 Jul 2011 at 7:07

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r977 == revision 401430e49618
r979 == revision 8ecb886ceab7

Original comment by g.rodola on 2 Mar 2013 at 12:00