Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process cpu_times() and memory_info() should raise NoSuchProcess for zombie processes #76

Closed
giampaolo opened this issue May 23, 2014 · 3 comments

Comments

@giampaolo
Copy link
Owner

From billiej...@gmail.com on February 22, 2010 23:42:12

What steps will reproduce the problem?  
>>> import psutil
>>> p = psutil.Process(3276)
>>> p.is_running()
True
>>> p.get_cpu_times()
(0.015600099999999999, 0.015600099999999999)
>>> p.get_memory_info()
(20480, 0)
>>> p.kill()
>>> p.is_running()
False
>>> p.get_cpu_times()
(0.015600099999999999, 0.015600099999999999)
>>> p.get_memory_info()
(20480, 0) 

What is the expected output?  


What do you see instead?  
I'd expect NoSuchProcess to be raised after the process has been killed. 

Please use labels and text to provide additional information.  
The test suite containes the following tests which were disabled on Windows
because of this issue:

# XXX - these tests are supposed to work everywhere except
# Windows which keeps returning info for a dead process.
if not sys.platform.lower().startswith("win32"):
    self.assertRaises(psutil.NoSuchProcess, p.get_cpu_times)
    self.assertRaises(psutil.NoSuchProcess, p.get_cpu_percent)
    self.assertRaises(psutil.NoSuchProcess, p.get_memory_info)
    self.assertRaises(psutil.NoSuchProcess, p.get_memory_percent)

Original issue: http://code.google.com/p/psutil/issues/detail?id=76

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 22, 2010 15:15:57

Fixed as r512 by having used GetExitProcess() to check whether the handle returned by
OpenProcess() is still alive.
I'm thinking that maybe we should use GetExitProcess() every time we use OpenProcess().
It is also possible that other functions suffer the same issue.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 22, 2010 15:17:18

Indeed, we faced this same problem in issue 36 which wasn't addressed at that time.
Closing this out as a duplicate.

Status: Duplicate

@giampaolo
Copy link
Owner Author

From g.rodola on March 02, 2013 03:51:43

Updated csets after the SVN -> Mercurial migration: r512 == revision 27636ff3db58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant