process.status raises an unhandled exception

[giampaolo]

From [email protected] on May 18, 2011 17:10:39

What steps will reproduce the problem?  
1. Execute the following code:
import psutil, os

p = psutil.Process(os.getpid())
p.status 

What is the expected output?  


What do you see instead?  
The expected output is the process status. I get an unhandled exception. 

What version of psutil are you using? What Python version?  
psutil-0.2.1. Python 2.7 

On what operating system? Is it 32bit or 64bit version?  
Windows XP SP3 - 32 bits 

Please provide any additional information below.  
I tried with some different processes with the same results.

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

[giampaolo]

From [email protected] on May 18, 2011 08:26:34

It would help immensely if you could post the actual output with the full 
exception traceback so we can analyze the issue. 

Thanks, 

-Jay

[giampaolo]

From [email protected] on May 18, 2011 08:35:38

I think I see what you're talking about, on my Win2003 box I can reproduce an 
error with the C code in get_process_info() crashing and causing the python 
process completely. I thought you were talking about a Python 
traceback/exception being raised. 

Thanks for the error report, since it's reproducible here that should help with 
debugging. I'll let you know if there's anything we need to look into this further.

Status: Accepted

[giampaolo]

From [email protected] on May 18, 2011 08:35:55

Labels: OpSys-Windows

[giampaolo]

From [email protected] on May 18, 2011 09:15:46

Ok this should be fixed in r973 now, try it out and let us know if you're still 
seeing a crash when retrieving the status

Status: FixedInSVN
Labels: Milestone-0.2.2

[giampaolo]

From [email protected] on May 18, 2011 18:43:54

The get_process_info function is incorrect. You can't return a pointer to the 
process structure since you free the buffer containing it right after! You can 
get the caller to free "buffer", or you can malloc a new block, copy the 
structure to there, free "buffer", then return the new block. Also, 
"*retProcess = &process;" is just incorrect pointer usage. Your previous 
version was correct (aside from the memory management).

[giampaolo]

From [email protected] on May 18, 2011 19:14:08

Thanks, fixed in r975 and have caller free the memory instead. I pinpointed the 
issue as the call to free() just misinterpreted the problem - appreciate the help :)

[giampaolo]

From [email protected] on May 18, 2011 19:21:31

You're returning "process", which is a pointer into "buffer", and you're 
freeing that pointer in is_process_suspended. That won't work. You need to 
return "buffer" directly.

[giampaolo]

From [email protected] on May 19, 2011 07:30:31

retProcess is now set to buffer, I think this is what you were suggesting? I 
tested it carefully and this appears to close any memory leaks and the crash is 
no longer reproducible on r976

[giampaolo]

From [email protected] on May 19, 2011 16:24:03

I'm afraid you do not fully understand what I'm saying. Your latest change is 
still incorrect because the caller will get a pointer to the first process 
structure, which is always for System Idle Process (PID 0). You need to return 
2 pointers. One is a pointer to the process structure found, and one is 
"buffer". The caller frees "buffer" after using the information.

[giampaolo]

From g.rodola on May 31, 2011 05:16:24

@Jay: I think you have broken a test ( r973 or r975 ):


======================================================================
FAIL: test_suspend_resume (__main__.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test\test_psutil.py", line 1021, in test_suspend_resume
    self.assertEqual(p.status, psutil.STATUS_STOPPED)
AssertionError: 0 != 3


@wj32.64: maybe you could provide a code snippet or a patch?

Owner: [email protected]

[giampaolo]

From [email protected] on May 31, 2011 07:47:41

> @Jay: I think you have broken a test ( r973 or r975 )

Yes, last revision was still incorrect. I was working on this the other day and 
haven't had a chance to circle back around to it.

[giampaolo]

From g.rodola on June 27, 2011 10:52:41

Labels: Milestone-0.3.0

[giampaolo]

From g.rodola on June 30, 2011 03:26:19

Reopening as the test is still failing.

Status: ReOpened

[giampaolo]

From g.rodola on July 02, 2011 11:05:46

Ok, I should have fixed this in r1060 .

Status: FixedInSVN

[giampaolo]

From g.rodola on July 08, 2011 12:07:35

Status: Fixed

[giampaolo]

From g.rodola on March 02, 2013 04:00:28

Updated csets after the SVN -> Mercurial migration: r973 == revision 
1209c537e980 r975 == revision c5bff6396245 r976 == revision f7492300a369 r1060 
== revision cae360d297e1