[tahoe-lafs-trac-stream] [tahoe-lafs] #1418: "cannot convert float NaN to integer" in next_power_of_k, during upload via helper

tahoe-lafs trac at tahoe-lafs.org
Fri Jun 24 08:49:39 PDT 2011


#1418: "cannot convert float NaN to integer" in next_power_of_k, during upload via
helper
------------------------+---------------------------
     Reporter:  rycee   |      Owner:  rycee
         Type:  defect  |     Status:  new
     Priority:  major   |  Milestone:  undecided
    Component:  code    |    Version:  1.8.2
   Resolution:          |   Keywords:  helper upload
Launchpad Bug:          |
------------------------+---------------------------

Comment (by rycee):

 Turns out Debian stable has a python2.6-dbg package.  I installed that and
 caught the SIGFPE when running the
 `allmydata.test.test_upload.EncodingParameters.test_upper_limit_on_readonly_queries`
 test (it also fails and runs quicker than the `test_backup` test).
 Anyway, I get
 {{{
 Program received signal SIGFPE, Arithmetic exception.
 0x0807de7c in int_float (v=0xa65a168) at ../Objects/intobject.c:945
 945     ../Objects/intobject.c: No such file or directory.
         in ../Objects/intobject.c
 (gdb) info float
   R7: Valid   0x400e9c42000000000000 +40002
   R6: Valid   0x400e9c42000000000000 +40002
   R5: Zero    0x00000000000000000000 +0
   R4: Valid   0x40029000000000000000 +9
   R3: Zero    0x00000000000000000000 +0
   R2: Zero    0x00000000000000000000 +0
   R1: Special 0xffff6edb1408f6ce3bbe Unsupported
 =>R0: Special 0xffffe649a0c99e4d8714 QNaN

 Status Word:         0xc2e1   IE             PE   ES   SF      C1    C3
                        TOP: 0
 Control Word:        0x1372      DM       UM PM
                        PC: Extended Precision (64-bits)
                        RC: Round to nearest
 Tag Word:            0x045a
 Instruction Pointer: 0x73:0x0807de79
 Operand Pointer:     0x7b:0x0a65a170
 Opcode:              0xdb40
 (gdb) where
 #0  0x0807de7c in int_float (v=0xa65a168) at ../Objects/intobject.c:945
 #1  0x08062c78 in PyNumber_Float (o=40000) at ../Objects/abstract.c:1749
 #2  0x0807d277 in float_new (type=0x822cf20, args=(40000,), kwds=0x0)
     at ../Objects/floatobject.c:1657
 #3  0x080accbd in type_call (type=0x822cf20, args=(40000,), kwds=0x0)
     at ../Objects/typeobject.c:726
 #4  0x0806232a in PyObject_Call (func=<type at remote 0x822cf20>,
 arg=(40000,),
     kw=0x0) at ../Objects/abstract.c:2492
 #5  0x080e016b in do_call (f=
     Frame 0xac1249c, for file /home/rycee/allmydata-
 tahoe-1.8.2/src/allmydata/immutable/upload.py, line 1331, in _got
 (params=(3, 1, 10, 40002), k=3, happy=1, n=10, segsize=40002,
 f=<cStringIO.StringI at remote 0xa5c83f8>,
 enckey_hasher=<_SHA256d_Hasher(_digest=None, h=<_sha256.SHA256 at remote
 0xb73bd700>, truncate_to=16) at remote 0x9c5f4cc>, BLOCKSIZE=65536,
 bytes_read=40000,
 data='datadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadatadata...(truncated),
 throwflag=0)
     at ../Python/ceval.c:3968
 Quit
 (gdb) print v
 $1 = (PyIntObject *) 0xa65a168
 (gdb) print *v
 $2 = {ob_refcnt = 2, ob_type = 0x822da20, ob_ival = 40000}
 }}}
 The failing line in `intobject.c` is `return PyFloat_FromDouble((double)(v
 -> ob_ival));` so presumably it is the cast to double that fails.  But
 since `ob_ival = 40000` I can't see any reasonable reason why.  The
 failing line in tahoe is `self._status.set_progress(0,
 float(bytes_read)/self._size)` in `immutable/upload.py`.

 If I have time, then I'll try the valgrind thingy but at the moment I'm
 pretty much ready to chalk it all up to hexed hardware.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1418#comment:25>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list