[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