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).