test_cmdline occasionally fails on Windows

[giampaolo]

From [email protected] on June 16, 2009 20:03:12

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: http://code.google.com/p/psutil/issues/detail?id=56

[giampaolo]

From [email protected] on June 17, 2009 10:38:52

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.

[giampaolo]

From [email protected] on September 17, 2009 03:13:37

Status: WontFix
Labels: -Milestone-0.1.3 OpSys-Linux

[giampaolo]

From g.rodola on September 24, 2010 16:40:43

Status: PostPoned

[giampaolo]

Closing this out as outdated.