Custom Query (72 matches)
Results (10 - 12 of 72)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #82 | fixed | valgrind warnings about branching on uninitialized data in OpenSSL | zooko | |
| Description |
I would assume that these are just more of the tradition of using uninitialized memory in your stateful ambient PRNG, and nothing to worry about, but it might be nice to get a little more information about them and it might help configure our builds to suppress these warnings, so I asked Ruben to install the OpenSSL debug lib. |
|||
| #81 | fixed | valgrind warnings with ld-2.15.so | zooko | |
| Description |
From #44: Hm, now the warning is back in a subsequent run: Let's see, here was the rebuild-the-exact-same-version (95c78ce5f08b03be70e5d69e5eb09d7acc1ce420) that I did earlier and it came out valgrind-clean:
And here is the rebuild of the exact same version again:
And the same valgrind warnings are back. David-Sarah told me to use a search engine, and I found this plausible explanation for this warning from Jakub Jellinek: |
|||
| #80 | fixed | segfault in Ed25519 on Fedora+gcc-4.7.0-prerelease | zooko | |
| Description |
https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/44 valgrind reports the following before the segfault occurs: ==9709== Invalid read of size 1 ==9709== at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40) ==9709== by 0xB4F8F23: crypto_sign_publickey (ed25519.c:30) ==9709== by 0xB4F7EEB: ed25519_publickey (ed25519module.c:48) ==9709== by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4E9C2BA: ??? (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4E86EEF: ??? (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4ECBC41: ??? (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4ECB8DB: ??? (in /usr/lib64/libpython2.7.so.1.0) ==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0) ==9709== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==9709== The first culprit I suspect is Fedora's pre-release of gcc 4.7.0, since this source passes tests (including valgrind clean) on several other platforms and since the underlying C code (i.e. sha512-hash.c) is used elsewhere, I think probably including in the nacl crypto lib from djb. |
|||
