[tahoe-dev] [tahoe-lafs] #737: python2.5 setup.py test runs CPU to 100% on 32-bit single-core NetBSD "4"

[tahoe-lafs]

#737: python2.5 setup.py test runs CPU to 100% on 32-bit single-core NetBSD "4"
---------------------------+------------------------------------------------
 Reporter:  midnightmagic  |           Owner:  warner
     Type:  defect         |          Status:  new   
 Priority:  major          |       Milestone:  1.5.0 
Component:  code           |         Version:  1.4.1 
 Keywords:                 |   Launchpad_bug:        
---------------------------+------------------------------------------------

Comment(by warner):

 yowza. Yeah, since foolscap's eventual() stuff always uses
 reactor.callLater(0), it must be in Twisted somewhere. Twisted will
 basically do (time.time()+delay), and we're passing in delay=0, so maybe
 time.time() is returning {{{NaN}}} ?

 First step, confirm that you can reproduce this in Foolscap (without
 Tahoe). Download the latest foolscap-0.4.2 (from pypi.python.org ... I'm
 having Trac problems on http://foolscap.lothar.com/trac and I can't edit
 the front page to reflect the 0.4.2 release). Then do {{{trial --until-
 failure foolscap.test.test_eventual}}}, which will run just the eventual-
 send -using tests.

 Assuming that fails in the same way, try this:
 {{{
 #!/usr/bin/python
 import time
 while True:
   t = time.time()
   assert t != float("NaN")
 }}}

 and see if that explodes. It's also likely that Twisted is subtracting a
 timestamp at some point (i.e. {{{delay = next_event - time.time()}}}) ..
 maybe subtraction of numbers that are too close to each other is creating
 a NaN?

 This reminds me of a problem I once had on a MIPS box running a not-quite-
 ready version of linux (one of the old Cobalt Qubes). I rebooted it once
 and Mailman (of all things) threw an exception saying "Eek! PI is greater
 than four!". I tracked it down to a bug in the kernel: it wasn't saving
 the floating-point registers during a context switch, so from a single
 process's point of view, its fp registers were corrupted at random times.
 Mailman happens to import the "math" module (for its exponential backoff
 algorithm), which gets its value of Pi from a C extension module (for
 improved accuracy or something). To make sure that the extension module
 was compiled and loaded properly, there was an import-time assertion like
 {{{3 <= PI <= 4}}}. And the floating-point register which held that value
 managed to be clobbered by a task-switch in the tiny interval between
 being loaded from memory and being tested by that assertion.

 Sometimes the fringe is a dangerous place :)

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/737#comment:5>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid