Failing tests on OS X

[GoogleCodeExporter]

What steps will reproduce the problem?
1. python setup.py build
2. python test/test_psutil.py

What is the expected output? What do you see instead?
I expect all implemented OS X tests to pass while running on OS X but instead I 
see that the following tests are failing for methods that are not new:

* test_get_connections_all
* test_phymem_usage

I also see this test is failing but it is related to Issue 125 where per-cpu 
times is not implemented on OS X yet:

* test_sys_per_cpu_times2

Note: Issue 125 has a patch submitted to implement per-cpu times and yet 
test_sys_per_cpu_times2 still fails.  It seems that the timeout in between 
gathering per-cpu tests needs to be greater to give a better chance for 
difference.

What version of psutil are you using? What Python version?
I'm using trunk (r1041).

On what operating system? Is it 32bit or 64bit version?
OS X 10.6.7 (64-bit)

Please provide any additional information below.

Original issue reported on code.google.com by jcscoob...@gmail.com on 22 Jun 2011 at 11:44

[GoogleCodeExporter]

Attached is a patch that fixes test_phymem_usage and test_sys_per_cpu_times2.  
I will look into test_get_connections_all next.

Note: Even after all this work is done there will be two failing tests on OS X: 
test_disk_partitions and test_disk_usage.  The work for these is actually being 
tracked in Issue 174 and Issue 172 respectively.

Original comment by jcscoob...@gmail.com on 22 Jun 2011 at 11:53

Attachments:

• fix_tests_on_osx.patch

[GoogleCodeExporter]

I have test_get_connections_all passing on OS X.  It seems that when you use 0 
or '' for the host or port for socket.bind(tuple) Python resorts to the OS to 
dictate how it connects.  While your test checks for "::1" for the local IP 
(127.0.0.1 in IPv4), on OS X 10.6.7 it's listening on "::" (0.0.0.0 in IPv4).  
The simple change would be to check that the local address is in ["::", "::1"] 
for the TCP and UDP tests for IPv6 support.  That being said, I have this fixed 
locally but since I have two patches in limbo already, I'll hold off on 
submitting any other diff to avoid change collision.

Original comment by jcscoob...@gmail.com on 23 Jun 2011 at 4:17

[GoogleCodeExporter]

Hi and thanks for the interest.
In r1043 I tried to fix test_phymem_usage and test_sys_per_cpu_times2.
I haven't checked though, since I got no OSX to test against at the moment.
Feel free to provide a patch for test_connections.

Original comment by g.rodola on 27 Jun 2011 at 8:16

• Changed state: Started

[GoogleCodeExporter]

I'm trying to rerun the tests and I think the fix disk usage committed is 
causing an issue.

python test/test_psutil.py
Traceback (most recent call last):
  File "test/test_psutil.py", line 29, in <module>
    import psutil
  File "/Users/jwhitlock/development/python/psutil/build/lib.macosx-10.6-universal-2.6/psutil/__init__.py", line 85, in <module>
    TOTAL_PHYMEM = _psplatform.phymem_usage()[0]
  File "/Users/jwhitlock/development/python/psutil/build/lib.macosx-10.6-universal-2.6/psutil/_psosx.py", line 32, in phymem_usage
    return ntuple_sysmeminfo(total, used, free, percent)
NameError: global name 'percent' is not defined

I'll commit a fix with my next patch.

Original comment by jcscoob...@gmail.com on 27 Jun 2011 at 4:07

[GoogleCodeExporter]

Attached is a patch that fixes the  test_get_connections_all and the broken 
phymem_usage for OS X.  I notice that test_sys_per_cpu_times2 is still failing 
because 0.1s is not enough time for CPU variance to differ by 0.5%.  I can only 
assume this is related to the system having multiple CPUs and maybe one of the 
CPUs hasn't differed much.  I attached a patch earlier that changed the sleep 
timeout to allow for more variance but it wasn't committed.  I went ahead an 
changed the time.sleep in test_sys_per_cpu_times2 so that tests pass locally 
other than the new API for partition information.

Original comment by jcscoob...@gmail.com on 27 Jun 2011 at 4:14

Attachments:

• fix_phymem_and_connections_all2_tests.patch

[GoogleCodeExporter]

I lied, I didn't change test_sys_per_cpu_times2 to have a longer sleep time but 
you should get the idea.  I have a new i7 with 4 real cores and 8 total 
virtual.  (I say 8 virtual because OS X reports 8 CPUs in Activity Monitor due 
to the i7 supporting Hyper-Threading (http://support.apple.com/kb/HT4180).  I 
think that since this system has so many reported CPUs, maybe one/more of the 
CPUs aren't changing much or at all in the 0.1 sleep.

Original comment by jcscoob...@gmail.com on 27 Jun 2011 at 4:18

[GoogleCodeExporter]

Ok I managed to install OSX on virtual box.
In r1045 I fixed the NameError exception and the connections-related test.

> I notice that test_sys_per_cpu_times2 is still failing because 0.1s 
> is not enough time for CPU variance to differ by 0.5

What thereshold is working for you? 
time.sleep(10) is way too much time to wait.
Does this change work for you?

- if not difference >= 0.05:
+ if not difference >= 0.01:

Original comment by g.rodola on 27 Jun 2011 at 4:32

[GoogleCodeExporter]

Okay, I looked into this more and 0.5 will fix test_sys_cpu_times2.  Where the 
problem lies is that in test_sys_per_cpu_times2, it's probably good but not all 
cores are differing by 0.05% which is why the test fails.  What if we bumped 
the sleep to 0.5 and in test_sys_per_cpu_times2 we test that at least one CPU 
varies by 0.05% instead of requiring all CPUs vary by that much?

Original comment by jcscoob...@gmail.com on 27 Jun 2011 at 4:42

[GoogleCodeExporter]

What about now (r1046)?

Original comment by g.rodola on 27 Jun 2011 at 4:46

[GoogleCodeExporter]

That seemed to do it.

Original comment by jcscoob...@gmail.com on 27 Jun 2011 at 4:48

[GoogleCodeExporter]

Cool. Closing out as fixed.

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

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r1041 == revision d2eb417fbb07
r1043 == revision 11ffad66d82d
r1045 == revision c27ef22ba263
r1046 == revision 1301c7d413ae

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