[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 rycee):

 Replying to [comment:49 davidsarah]:
 > Replying to [comment:48 rycee]:
 > > Note, when I used `--disable-embedded-cryptopp` it was built against
 the Debian version of Crypto++ 5.6.0 since I don't know how to convince
 `setup.py` to look for headers and libraries in a non-standard directory.
 It still fails in the same way, though, if I use LD_LIBRARY_PATH to force
 it to load the upstream Crypto++ 5.6.0.
 >
 > This is almost sufficient to convince me that this is a fixed bug in
 Crypto++ (despite it not being clear which change fixed it). However, we
 haven't excluded the possibility that the problem interacts with the
 dynamic linking, i.e. that it fails in non-embedded mode.
 Ok, so I tried a new way. I unpacked pycryptopp twice. In one of the trees
 I replaced the `embeddedcryptopp` directory by a pristine upstream
 Crypto++ 5.6.0 and in the other I replaced `embeddedcryptopp` by a
 pristine upstream Crypto 5.6.1. I then did a `python setup.py build`
 followed by `python setup.py test` in each of the two trees. The
 pycryptopp statically built with 5.6.0 failed the test (in the same way as
 the previously attached test log) while the build using Crypto++ 5.6.1 ran
 all tests successfully.

 I'm a bit curious, however, as to why the `cryptest.exe` program from
 Crypto++ 5.6.0 didn't fail, maybe the failing test from pycryptopp could
 be ported to a test in `cryptest.exe`?

 > > Using the same technique to force it to use Crypto++ 5.6.1 results in
 an undefined symbol error.
 >
 > It sounds like we should open a new (pycryptopp) ticket for that, since
 at some point Debian or Ubuntu will upgrade to 5.6.1 and then it may fail
 with the same error.
 It's like [comment:50 zooko said]. Since I don't know how to make
 `setup.py` use a custom directly header-directory it built against the
 standard Debian Cryptop++ 5.6.0 headers.

 However, curiously enough, when I used Debian's pycryptopp – which is
 dynamically linked against Debian's Crypto++ – I ''was'' able to change
 out the `.so` file from 5.6.0 to 5.6.1 without problem. Doing this is how
 I found out that 5.6.1 worked. I suppose it has something to do with the
 patches and how the Debian pycryptopp and Crypto++ packages are built.

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