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

[tahoe-lafs]

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

Comment (by zooko):

 Replying to [comment:5 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?)

 No, the
 [source:trunk/src/allmydata/util/assertutil.py?annotate=blame&rev=4329
 precondition()] function runs the tests regardless of any flags. (There is
 a flag in Python to disable {{{assert}}}, but {{{precondition()}}} doesn't
 use {{{assert}}} or respect that flag.)

 Oh, I guess my patch was written under the mistaken assumption that this
 {{{NaN}}} was arising because one of the inputs to {{{math.log()}}} was
 not an int or long. I'll need to think harder to provide a more useful
 diagnostics patch, probably starting by re-reading davidsarah's comment:2.


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

 Wait a minute, are you saying that {{{tahoe cp}}} reports {{{Success:
 files copied}}} even though the helper encountered this uncaught
 exception!? That seems unlikely. Which process encounters the uncaught
 exception and in which step of the transcript above?

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