Fix spurious exception when iterating processes on Solaris

[dbeer1]

On our Solaris machines, we get periodic exceptions when iterating the process table with psutil. Simple code like this:

import psutil
for proc in psutil.process_iter():
    print(proc)

Will regularly result in an exception:

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/psutil/_common.py", line 341, in wrapper
    ret = self._cache[fun]
AttributeError: _cache

During handling of the above exception, another exception occurred:

RuntimeError: process doesn't have arguments block

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.6/site-packages/psutil/__init__.py", line 498, in __str__
    info["name"] = self.name()
  File "/usr/lib/python3.6/site-packages/psutil/__init__.py", line 726, in name
    name = self._proc.name()
  File "/usr/lib/python3.6/site-packages/psutil/_pssunos.py", line 351, in wrapper
    return fun(self, *args, **kwargs)
  File "/usr/lib/python3.6/site-packages/psutil/_pssunos.py", line 419, in name
    return self._proc_name_and_args()[0]
  File "/usr/lib/python3.6/site-packages/psutil/_pssunos.py", line 351, in wrapper
    return fun(self, *args, **kwargs)
  File "/usr/lib/python3.6/site-packages/psutil/_common.py", line 344, in wrapper
    return fun(self)
  File "/usr/lib/python3.6/site-packages/psutil/_pssunos.py", line 402, in _proc_name_and_args
    return cext.proc_name_and_args(self.pid, self._procfs_path)
SystemError: <built-in function proc_name_and_args> returned a result with an error set

This exception happens while reading the process arguments for a process with a long command line. Normally, the proc_name_and_args function reads the process arguments from the pr_psargs string in the psinfo_t struct, but it tries using the pr_argv value (a pointer to argv in the target process) instead if it detects the former may be truncated. The code is then supposed to fall back to the truncated pr_psargs if this fails (according to comments in there at least).

However, the error indicator is never cleared if the first method fails. So even if it can successfully get the arguments using the second method, an exception is still thrown. This change clears the error indicator between attempts to get the process arguments, so if they can be read successfully than no exception is thrown.

[gaborbernat]

hello can you let us know when you can do a release with this? thanks!