[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:  rycee
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  code     |    Version:  1.8.2
   Resolution:           |   Keywords:  helper upload heisenbug
Launchpad Bug:           |  floatingpoint debian pycryptopp
-------------------------+-------------------------------------------------

Comment (by zooko):

 Hm, well okay so we're pretty sure there is a bug in Crypto++ 5.6.0 that
 is fixed in Crypto++ 5.6.1, right? Maybe we could let it go at that, since
 it is apparently fixed. The steps to reproduce are:

 1. Get and build Crypto++ 5.6.0
 2. Build pycryptopp with the {{{--disable-embedded-cryptopp}}} option so
 that it will link against the .so generated in step 1 instead of using its
 own bundled copy of Crypto++ source code
 3. Run {{{python setup.py test -s
 allmydata.test.test_cli.Backup.test_backup}}}

 On your machine this 100% reproducible triggers the problem, and swapping
 in Crypto++ 5.6.1 for 5.6.0 makes it stop happening?

 Okay one more thing: how do I know I don't have the same bug in the copy
 of Crypto++ that is bundled inside pycryptopp? I don't think we've
 upgraded the embedded copy of Crypto++ a newer version of Crypto++ since
 this patch [91f454b47f66636fffde68e8a8bf4364bed7516e]:

 {{{
 commit 91f454b47f66636fffde68e8a8bf4364bed7516e
 Author: weidai <weidai>
 Date:   Sat Feb 2 00:40:27 2008 -0800
 }}}

 Four years ago, before Crypto++ 5.6.0 [http://cryptopp.com/#news was
 released]. Since then we've just been cherry-picking patches from upstream
 Crypto++. So if this bug was present in the version that we copied, and if
 we didn't realize that we needed to cherry-pick the patch that fixes it,
 then it could be present in the embedded copy of Crypto++ inside
 pycryptopp.

 Could you please replace step 2 above with building and omitting the
 {{{--disable-embedded-cryptopp}}} flag, to force it to use its embedded
 version of Crypto++? I think you've probably done that already in this
 process, but if you could do it again now just to be sure, that would make
 me feel better.

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