Bug 790114

I opened a ticket on launchpad.net with which to track the progress of this issue across multiple other issue trackers: pycryptopp, GCC, Fedora, and possibly DJB's "nacl" crypto library if there is any way to track such issues other than emailing the author. https://bugs.launchpad.net/pycryptopp/+bug/931542

You've filed lots of bugreports, but haven't provided easy steps how to reproduce, what exactly when built with gcc 4.7 fails, what (if possible minimal) command to reproduce it.

By the way, I don't know for sure that this is a bug in gcc-4.7.0-prerelease. It could also be a bug in our code which is uncovered by a recent change in gcc, for example. I do know that the same segfault doesn't happen on the other buildbots, none of which have gcc >= 4.7.0-prerelease.

I can explain how to reproduce it, but I can't conveniently generate a minimal case, since I don't currently have access to system (e.g. Rawhide) with gcc-4.7.0-prerelease on.

To reproduce (not minimally):

git checkout git://github.com/tahoe-lafs/pycryptopp.git
cd pycryptopp
git reset --hard 36a666d4514e21a71c934bcfc62438b8bab97f32

# Note that an equivalent git checkout is done automatically by the buildbot. The exact command-line, environment, and stdout+stderr are logged, e.g. here: https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/49/steps/git/logs/stdio

python setup.py build --test-double-load

# This builds the C and C++ modules. I would assume that the option --test-double-load to the command-line is irrelevant to this bug (it causes another module to be built which isn't used by the program which segfaults). Here's a log of the buildbot executing this step and the resulting output: https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/49/steps/compile/logs/stdio

valgrind --error-exitcode=1 --log-file=valgrind.log.txt --suppressions=misc/coding_helpers/python.supp --gen-suppressions=all python setup.py test

# This runs the pycryptopp unit tests, which trigger the segfault. Here's a log of the command-line, env var, and stdout+stderr of buildbot executing this step: https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/49/steps/test%20valgrind/logs/stdio
# Here's the valgrind log file that results from that command-line as executed by the buildbot: https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/49/steps/test%20valgrind/logs/valgrind

# By the way, here is some information about the system on which that buildbot test runs:
# https://tahoe-lafs.org/buildbot-pycryptopp/buildslaves/buildbot.rubenkerkhof.com
# https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora/builds/49/steps/show-tool-versions/logs/stdio

If I were going to minimize this, I would start by looking at the Python unit test which reliably executes, the bug: pycryptopp.test.test_ed25519.Basic.test_OOP . First I would run that test alone and not the other tests, by changing "python setup.py test" to "python setup.py test -s pycryptopp.test.test_ed25519.Basic.test_OOP", just to be sure the other tests running doesn't change the behavior. If it doesn't, then I would add some debug print statements in the source code of test_OOP: https://github.com/tahoe-lafs/pycryptopp/blob/36a666d4514e21a71c934bcfc62438b8bab97f32/pycryptopp/test/test_ed25519.py#L124 to see which of its calls to ed25519, and with what arguments, triggers the segfault. Then I would write equivalent C code and see if that triggers the segfault.

Thanks to Samuel Neves, the bug was identified in pycryptopp. Thanks!