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

 Replying to [comment:51 rycee]:
 > Replying to [comment:49 davidsarah]:
 > > Replying to [comment:48 rycee]:
 [...]
 > 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`?

 The bug seems to affect the floating point state, and it's quite plausible
 that `cryptest.exe` doesn't test for that. A regression test would indeed
 be nice -- if you're sufficiently motivated then I suggest asking on the
 Crypto++ mailing list.

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

 Yes, as Zooko said this is an invalid test.

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

 Ah, so if that worked then it is not the dynamic linking. Okay, let's stop
 worrying about this one.

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