generates-bad-code regression
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MinGW |
Unknown
|
Unknown
|
|||
Tahoe-LAFS |
Fix Released
|
Unknown
|
|||
binutils |
Fix Released
|
Medium
|
|||
pycryptopp |
Fix Released
|
Unknown
|
|||
binutils (Fedora) |
Fix Released
|
Medium
|
|||
binutils (Ubuntu) |
Fix Released
|
Medium
|
Matthias Klose | ||
Karmic |
Fix Released
|
Medium
|
Matthias Klose | ||
libcrypto++ (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Karmic |
Invalid
|
Undecided
|
Unassigned |
Bug Description
g++-4.4 4.4.1-3ubuntu3 was used to build libcrypto++8. The current g++-4.4 in Karmic is g++-4.4 4.4.1-4ubuntu8. When 4.4.1-4ubuntu8 is used to build libcrypto++8 then the libcrypto++8 self-tests hang during the SHA validation. It appears that there has been a regression between g++ 4.4.1-3ubuntu3 and -4ubuntu8 such that the new one generates bad code.
In addition to the libcrypto++8 self-tests hanging during SHA validation, if you then build python-pycryptopp using the libcrypto++8 lib that was built by g++ 4.4.1-4ubuntu8, then the python-pycryptopp library gets segfaults when it runs its self-tests. Here is the pycryptopp upstream buildbot showing segfaults on karmic, along with a valgrind report:
http://
http://
affects: | ubuntu → gcc-4.4 (Ubuntu) |
tags: | added: regression-potential |
affects: | gcc-4.4 (Ubuntu) → binutils (Ubuntu) |
Changed in binutils (Ubuntu Karmic): | |
status: | Confirmed → In Progress |
Changed in libcrypto++ (Ubuntu Karmic): | |
status: | New → Invalid |
Changed in binutils (Ubuntu Karmic): | |
milestone: | none → karmic-updates |
Changed in binutils: | |
status: | Unknown → Fix Released |
tags: |
added: verification-done removed: verification-needed |
Changed in binutils (Ubuntu): | |
status: | Fix Committed → Fix Released |
milestone: | karmic-updates → none |
Changed in tahoe-lafs: | |
status: | Unknown → New |
Changed in tahoe-lafs: | |
status: | New → Fix Released |
Changed in binutils (Fedora): | |
status: | Unknown → In Progress |
Changed in pycryptopp: | |
status: | Unknown → Fix Released |
Changed in binutils: | |
importance: | Unknown → Medium |
Changed in binutils (Fedora): | |
importance: | Unknown → Medium |
status: | In Progress → Fix Released |
Hold on, the reason that I stated that g++ 4.4.1-3ubuntu3 built good code is as follows:
1. The resulting libcrypto++8 is in Karmic, so it must have passed its self-test which happens automatically when you build it, right?
2. If you link pycryptopp to the resulting libcrypto++8 which is in Karmic, the pycryptopp passes all of its self-tests including under valgrind: here is the builder which does this: http:// allmydata. org/buildbot- pycryptopp/ builders/ linux-amd64- ubuntu- karmic- yukyuk- syslib (in contrast, here is the builder which attempts to build the same version of pycryptopp but compile Crypto++ itself from source instead of using the libcrypto++8 which is included in Karmic: http:// allmydata. org/buildbot- pycryptopp/ builders/ linux-amd64- ubuntu- karmic- yukyuk . That one fails.)
However, I just now finished getting a pbuilder chroot configured with g++-4.4 4.4.1-3ubuntu3 and when I pbuild libcrypto++8 then it hangs in its SHA self-test!
So, how did libcrypto++8 as built by g++ 4.4.1-3ubuntu3 pass its self tests? Or *did* it pass its self-tests before it went into Karmic?