search

tigerneil / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

test_cmdline occasionally fails on Windows #56

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
It's since version 0.1.0 that I keep seeing this test failing every now and
then so I decided to track this down and hopefully decide a solution.

If I'm not mistaken this should be due to the process which is queried by
psutil when it is not properly initialized yet.

If this is the case I would suggest to raise a NoSuchProcess exception
rather than filling the cmdline with an empty list as it seems we're
deliberately doing right now.

======================================================================
FAIL: test_cmdline (__main__.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\pyftpdlib\svn\psutil\test\test_psutil.py", line 233, in test_cmdline
    self.assertEqual(psutil.Process(self.proc.pid).cmdline, [PYTHON, "-E"])
AssertionError: [] != ['C:\\Python26\\python.exe', '-E']

----------------------------------------------------------------------

Original issue reported on code.google.com by billiej...@gmail.com on 16 Jun 2009 at 6:03

GoogleCodeExporter commented 9 years ago 
If it were that easy to fix, then we would have fixed it already ;)

The core problem is that ReadProcessMemory calls occasionally fail with an 
error that
only part of the request completed. I don't know what causes this, and there's 
really
no way to know if it's being caused by a process entry still being initialized 
or if
it's a memory read error from another source. I've tried looping when this error
occurs to see if we can retry the ReadProcessMemory request. However, once it 
fails
repeating the attempt doesn't seem to make a difference and it continues to 
fail for
subsequent attempts.

Bear in mind that get_arg_list() which does the work to read the process 
command line
is also using handle_from_pid() which already checks the exit code of the 
process
etc. to make sure that the process exists. We're already doing all we can to 
ensure
the process is valid before we try to read the command line, but it's not 100%
reliable. It's possible we may eventually determine some kind of workaround but 
at
the moment I think this is just an unavoidable side effect of the fact that 
we're
using an unsupported API to read the memory of another process to determine its
commandline. We may just have to live with some occasional errors. My vote 
would be
to mark this as WontFix for the time being.

Original comment by jlo...@gmail.com on 17 Jun 2009 at 5:38

GoogleCodeExporter commented 9 years ago

Original comment by billiej...@gmail.com on 17 Sep 2009 at 10:13

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 24 Sep 2010 at 11:40