process.status raises an unhandled exception

[GoogleCodeExporter]

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 reported on code.google.com by fdv...@gmail.com on 18 May 2011 at 3:10

[GoogleCodeExporter]

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

Thanks, 

-Jay

Original comment by jlo...@gmail.com on 18 May 2011 at 3:26

[GoogleCodeExporter]

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.

Original comment by jlo...@gmail.com on 18 May 2011 at 3:35

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by jlo...@gmail.com on 18 May 2011 at 3:35

• Added labels: OpSys-Windows

[GoogleCodeExporter]

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

Original comment by jlo...@gmail.com on 18 May 2011 at 4:15

• Changed state: FixedInSVN
• Added labels: Milestone-0.2.2

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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).

Original comment by wj32...@gmail.com on 19 May 2011 at 1:43

[GoogleCodeExporter]

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 :)

Original comment by jlo...@gmail.com on 19 May 2011 at 2:14

[GoogleCodeExporter]

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.

Original comment by wj32...@gmail.com on 19 May 2011 at 2:21

[GoogleCodeExporter]

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

Original comment by jlo...@gmail.com on 19 May 2011 at 2:30

[GoogleCodeExporter]

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.

Original comment by wj32...@gmail.com on 19 May 2011 at 11:24

[GoogleCodeExporter]

@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?

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

[GoogleCodeExporter]

> @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.

Original comment by jlo...@gmail.com on 31 May 2011 at 2:47

[GoogleCodeExporter]

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

• Added labels: Milestone-0.3.0

[GoogleCodeExporter]

Reopening as the test is still failing.

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

• Changed state: ReOpened

[GoogleCodeExporter]

Ok, I should have fixed this in r1060.

Original comment by g.rodola on 2 Jul 2011 at 6:05

• 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:
r973 == revision 1209c537e980
r975 == revision c5bff6396245
r976 == revision f7492300a369
r1060 == revision cae360d297e1

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