======================================================================
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jan/src/python26/Lib/test/test_signal.py", line 368, in 
test_itimer_virtual
    self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0))
AssertionError: (0.17993600000000001, 0.20000000000000001) != (0.0, 0.0)

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

Complete output attached.

test_signal does not fail for me on 10.6 using the python.org 2.6.3 
installer (which is 32-bit).  The test hangs (presumably in the wait 
loop) with a 10.6 64-bit build of Python 2.6.3rc1.  FWIW, the 2.6.3 
test_signal seems to run OK with Apple's 64-bit python2.6.2 in 10.6. 
What kind of build and on what kind of machine were you running this?

There are other issues open that report similar problems running 
test_signal on other OS's: http://bugs.python.org/issue5972, which was 
reported against Red Hat Linux 4.1.2, and possibly 
http://bugs.python.org/issue3864 on FreeBSD.  Perhaps there's a common 
thread here.

This is a 64 bit machine and the test failed for the checkout of the 
python26-maint branch. I just configured and made it without any flags. 
(Does that produce a 64 bit build?)

By default, 10.6 prefers to run 64-bit architectures when available.  You 
can easily tell whether a python 2.x is running as 32-bit or 64-bit by 
checking sys.maxint:

$ /usr/local/bin/python2.6 -c 'import sys; print sys.maxint'
2147483647
$ /usr/bin/python2.6 -c 'import sys; print sys.maxint'
9223372036854775807

$ ./python.exe -c 'import sys; print sys.maxint'
9223372036854775807

I'm seeing this failure too, on a 64-bit build of the trunk on OS X 
10.6.1.

If I understand the test, it's setting up a timer that's supposed to run 
for 0.3 seconds of 'virtual time', signal, and then signal every 0.2 
seconds of virtual time thereafter.  The test passes after 4 (or is it 3?) 
signals have been handled, for a total of 0.9 seconds of virtual time.

The problem appears to be that the 'for i in xrange(100000000): ...' loop 
simply isn't long enough for 0.9 seconds of virtual time to even elapse:  
on my machine, around 0.06 seconds of virtual time appear to have elapsed 
by the time the loop is finished.

When I increase the loop to 'for i in xrange(10**10): ...', the test 
*eventually* passes.  Those 0.9 seconds of virtual time took over 29 
minutes of real time, on an otherwise mostly-idle machine.  (2.53GHz Core 
2 Duo.)

When I add some actual work into the xrange loop (computing pow(12345, 
67890, 10000001) and throwing away the result) then test_itimer_virtual 
passes, in a reasonably short amount of time (a second or so).

I don't know what the precise definition of virtual time is, or whether 
there's a defect in the way that Snow Leopard is measuring it.  At any 
rate, I don't think the reported behaviour is a bug in the signal module:  
the test should be fixed somehow, though (perhaps by adding that pow() 
call).

Issue #5972 looks like the same problem.

This may also explain why the x86 FreeBSD trunk buildbot is currently 
hanging on test_signal.

(And I see Ned already mentioned issue 5972 above.  Sorry for the noise.)

chuck: does the attached patch fix the problem for you?

I've applied the above patch in r75236 (trunk), r75237 (release26-maint),
r75238 (py3k) and r75239 (release31-maint).  With any luck this should fix 
the issue.  Jan Hosang, can you confirm that this is fixed?

I updated the checkout of the 26 branch, and the test runs fine now.

I have no clue about virtual time as well. If this is about passing time, 
there should be better ways (than those which break if your computer gets 
faster).

> If this is about passing time, there should be better ways (than
> those which break if your computer gets faster).

Agreed.  The challenge is to find ways that don't add too much in the
way of extra complexity, fragility, or dependencies to the unit test.

How about replacing the xrange(100000000) loop with something like this,
which allows 30 seconds of real time and then fails with a timeout 
message:

start_time = time.time()
while time.time() - start_time < 5.0:
    <use some process time here>
    if signal.getitimer(self.itimer) == (0.0, 0.0):
        break
else:
    self.fail('timeout waiting for virtual timer signal')

Oops.  That 5.0 should have been 30.0, of course.

I think a timing out while loop explains much better what is happening. I 
mean we are trying to keep the cpu busy for 0.9 seconds (if I understand 
the definition of virtual time correctly) and not do 100000000 increments 
(which might be done faster than 0.9 seconds).

I've fixed test_itimer_virtual and test_itimer_prof to use a timeout 
instead of an xrange/range(100000000) loop, in r75986 through r75989.