[tahoe-lafs-trac-stream] [tahoe-lafs] #1418: "cannot convert float NaN to integer" in next_power_of_k

[tahoe-lafs]

#1418: "cannot convert float NaN to integer" in next_power_of_k
-------------------------+-----------------------------
     Reporter:  rycee    |      Owner:  rycee
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  unknown  |    Version:  1.8.2
   Resolution:           |   Keywords:  response-needed
Launchpad Bug:           |
-------------------------+-----------------------------

Comment (by rycee):

 With zooko's patch I get pretty much the same thing as earlier (do I need
 to give python some special flags to enable the preconditions?):

 {{{
 [snip]
 --- <exception caught here> ---
   File "/home/rycee/allmydata-tahoe-1.8.2.foo/support/lib/python2.6/site-
 packages/Twisted-10.2.0-py2.6-linux-i686.egg/twisted/internet/defer.py",
 line 542, in _runCallbacks
     current.result = callback(current.result, *args, **kw)
   File "/home/rycee/allmydata-
 tahoe-1.8.2/src/allmydata/immutable/upload.py", line 926, in
 locate_all_shareholders
     num_segments, n, k, desired)
   File "/home/rycee/allmydata-
 tahoe-1.8.2/src/allmydata/immutable/upload.py", line 225, in
 get_shareholders
     None)
   File "/home/rycee/allmydata-
 tahoe-1.8.2/src/allmydata/immutable/layout.py", line 88, in
 make_write_bucket_proxy
     num_share_hashes, uri_extension_size_max, nodeid)
   File "/home/rycee/allmydata-
 tahoe-1.8.2/src/allmydata/immutable/layout.py", line 108, in __init__
     effective_segments = mathutil.next_power_of_k(num_segments,2)
   File "/home/rycee/allmydata-tahoe-1.8.2/src/allmydata/util/mathutil.py",
 line 35, in next_power_of_k
     x = int(math.log(n, k) + 0.5)
 exceptions.ValueError: cannot convert float NaN to integer
 }}}

 Please note that upload.py:926 now appear in the stack compared to
 upload.py:924 in the initial stack so the patch was really applied!  I
 checked this many times to convince myself that I'm not going insane :-)

 After a bit of further investigation it seems like the problem only occurs
 when I'm using a helper.  When uploading directly from my client node it
 works perfectly fine.  When I realized this I also realized that it is
 possible that since upgrading the helper node to 1.8.2, I have only used
 the client without helper!  I did successfully use the helper when it was
 running 1.8.1 though.  I don't know if this helps you narrow down the
 problem.

 Disabling the use of helper and uploading a random file gives:

 {{{
 $ dd if=/dev/urandom of=rnd0 bs=1M count=1
 1+0 records in
 1+0 records out
 1048576 bytes (1.0 MB) copied, 0.256792 s, 4.1 MB/s
 $ tahoe cp rnd0 priv:
 Success: files copied
 $ tahoe check priv:rnd0
 Summary: Healthy
  storage index: fpeoa7vqrcrjny354zmru3gqda
  good-shares: 3 (encoding is 1-of-3)
  wrong-shares: 0
 $ tahoe check --verify priv:rnd0
 Summary: Healthy
  storage index: fpeoa7vqrcrjny354zmru3gqda
  good-shares: 3 (encoding is 1-of-3)
  wrong-shares: 0
 }}}

 which is good.  However, when I enable the use of a helper and restart the
 client node I get:

 {{{
 $ dd if=/dev/urandom of=rnd1 bs=1M count=1
 1+0 records in
 1+0 records out
 1048576 bytes (1.0 MB) copied, 0.256289 s, 4.1 MB/s
 $ tahoe cp rnd1 priv:
 Success: files copied
 $ tahoe check priv:rnd1
 Summary: Healthy
  storage index: rzlouseev5hbrte62facntsj4i
  good-shares: 3 (encoding is 1-of-3)
  wrong-shares: 0
 $ tahoe check --verify priv:rnd1
 Summary: Not Healthy: 0 shares (enc 1-of-3)
  storage index: rzlouseev5hbrte62facntsj4i
  good-shares: 0 (encoding is 1-of-3)
  wrong-shares: 0
  corrupt shares:
   server bzyf23mghgxycnr34pdkqdmybnevf4ks, SI rzlouseev5hbrte62facntsj4i,
 shnum 2
   server 44g5kkgwulzrrrntdzci7jtt5rgt6nuo, SI rzlouseev5hbrte62facntsj4i,
 shnum 0
   server 5yea4my3w3frgp524lgthrb7rdd6frtr, SI rzlouseev5hbrte62facntsj4i,
 shnum 1
 }}}

 which is bad.

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