Using this version of gcc-4.7.0 prerelease which is shipped in Fedora Rawhide: 4.7.0 20120126 (Red Hat 4.7.0-0.10), the resulting code segfaults. Valgrind reports this:
==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==
{
<insert_a_suppression_name_here>
Memcheck:Addr1
fun:crypto_hash_sha512
fun:crypto_sign_publickey
fun:ed25519_publickey
fun:PyEval_EvalFrameEx
fun:PyEval_EvalCodeEx
obj:/usr/lib64/libpython2.7.so.1.0
fun:PyObject_Call
obj:/usr/lib64/libpython2.7.so.1.0
fun:PyObject_Call
obj:/usr/lib64/libpython2.7.so.1.0
obj:/usr/lib64/libpython2.7.so.1.0
fun:PyObject_Call
}
==9709==
==9709== Process terminating with default action of signal 11 (SIGSEGV)
==9709== Access not within mapped region at address 0x0
==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)
More detail, including access to a buildbot which can reliably reproduce the problem on Fedora Rawhide and demonstrate no such problem on several other platforms, is here: https://tahoe-lafs.org/trac/pycryptopp/ticket/80
Using this version of gcc-4.7.0 prerelease which is shipped in Fedora Rawhide: 4.7.0 20120126 (Red Hat 4.7.0-0.10), the resulting code segfaults. Valgrind reports this:
==9709== Invalid read of size 1 sign_publickey (ed25519.c:30) c:48) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) a_suppression_ name_here> crypto_ hash_sha512 crypto_ sign_publickey ed25519_ publickey PyEval_ EvalFrameEx PyEval_ EvalCodeEx /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call /usr/lib64/ libpython2. 7.so.1. 0 /usr/lib64/ libpython2. 7.so.1. 0 PyObject_ Call sign_publickey (ed25519.c:30) c:48) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0) libpython2. 7.so.1. 0)
==9709== at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40)
==9709== by 0xB4F8F23: crypto_
==9709== by 0xB4F7EEB: ed25519_publickey (ed25519module.
==9709== by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/
==9709== by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/
==9709== by 0x4E9C2BA: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4E86EEF: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4ECBC41: ??? (in /usr/lib64/
==9709== by 0x4ECB8DB: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9709==
{
<insert_
Memcheck:Addr1
fun:
fun:
fun:
fun:
fun:
obj:
fun:
obj:
fun:
obj:
obj:
fun:
}
==9709==
==9709== Process terminating with default action of signal 11 (SIGSEGV)
==9709== Access not within mapped region at address 0x0
==9709== at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40)
==9709== by 0xB4F8F23: crypto_
==9709== by 0xB4F7EEB: ed25519_publickey (ed25519module.
==9709== by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/
==9709== by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/
==9709== by 0x4E9C2BA: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4E86EEF: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
==9709== by 0x4ECBC41: ??? (in /usr/lib64/
==9709== by 0x4ECB8DB: ??? (in /usr/lib64/
==9709== by 0x4E78A1D: PyObject_Call (in /usr/lib64/
More detail, including access to a buildbot which can reliably reproduce the problem on Fedora Rawhide and demonstrate no such problem on several other platforms, is here: https:/ /tahoe- lafs.org/ trac/pycryptopp /ticket/ 80