Bug 52236 - segfault in program that results from compiling sha512-hash.c
Summary: segfault in program that results from compiling sha512-hash.c
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2012-02-13 17:00 UTC by Zooko Wilcox-O'Hearn
Modified: 2012-02-15 21:22 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-02-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zooko Wilcox-O'Hearn 2012-02-13 17:00:37 UTC
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
Comment 1 Zooko Wilcox-O'Hearn 2012-02-13 17:03:49 UTC
The host is linux x86_64. More information about the platform is queried automatically by the buildbot and archived here: https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/44/steps/show-tool-versions/logs/stdio

platform: Linux-3.2.1-8.fc17.x86_64-x86_64-with-fedora-17-Rawhide
machine:  x86_64
linux_distribution: ('Fedora', '17', 'Rawhide')
Comment 2 Zooko Wilcox-O'Hearn 2012-02-13 17:17:37 UTC
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
Comment 3 Jakub Jelinek 2012-02-13 17:40:38 UTC
Please read http://gcc.gnu.org/bugs.html, you should provide a self-contained and if possible small testcase, it could very well be a bug in the application you are using.  If you suspect a gcc bug, you can use use either a debugger or brute-force - e.g. binary search in between objects compiled with various compilation flags or various versions of the compiler (-O0 vs. standard flags, or standard flags + -fno-strict-aliasing, etc.).
Comment 4 Zooko Wilcox-O'Hearn 2012-02-15 21:22:28 UTC
Thanks to Samuel Neves, the bug was identified in the application (pycryptopp), not in gcc. Thanks!