Bug 1025072 - libstdc++/58800 (the bug, not the fix) just got backported to Fedora 19 and 20
libstdc++/58800 (the bug, not the fix) just got backported to Fedora 19 and 20
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks: 1040708
  Show dependency treegraph
 
Reported: 2013-10-30 19:33 EDT by Andy Lutomirski
Modified: 2013-12-19 21:02 EST (History)
13 users (show)

See Also:
Fixed In Version: gcc-4.8.2-7.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-16 02:09:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Lutomirski 2013-10-30 19:33:07 EDT
The latest gcc in Fedora 19 contains libstdc++/58800 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800), which is a really unpleasant bug.  (It's a 4.8.2 regression, I think, and it's fixed upstream.)

Please backport the fix, too.  The number of random crashes I'm seeing is remarkable.

(This could even be a security bug -- if you can get someone to try to compute the median of a short malicious list, they'll overrun the list.)
Comment 1 Andy Lutomirski 2013-11-26 19:41:02 EST
This is apparently fixed in 4.8.2-4, but that's been sitting in f19-updates-candidate for quite a while.  Is there a reason that it hasn't been pushed to updates-testing?
Comment 2 Adam Williamson 2013-12-06 17:29:37 EST
OK, so I'm provisionally pulling the 'oh shit' horn on this one, folks.

As described by Andy - if I understand correctly - any code built with gcc 4.8.2-1 "that calls std::nth_element will call a buggy (inline) implementation".

4.8.2-2 is listed as fixing the problem, but it was never submitted as an update. 4.8.2-1 went stable for F20 on 2013-11-10 06:51:41 , so everything built since then was built with this gcc. That means, if I'm understanding the issue correctly, anything built since 2013-11-10 which calls std::nth_element is now broken. That could be a big deal.

Can someone who actually knows about...building...code and stuff please take a look at this, as a priority, and see if it's as bad as it seems? on the face of it, looks like we might need to figure out what builds could be affected and re-do them all.
Comment 3 Adam Williamson 2013-12-06 17:32:07 EST
For F19, gcc 4.8.2-1 went stable on 2013-10-29 03:36:44 , so anything built since then is potentially affected.
Comment 4 Adam Williamson 2013-12-06 17:39:10 EST
<jakub> adamw: I guess you can inspect debug info of packages built on or after Oct 29 to see which packages inline that method
 adamw: likely a couple of them do, but I think most don't
 adamw: I think elfutils handles dwz compressed debug enough well enough these days that just installing the debuginfo of all those packages and running eu-readelf -wi or similar could do the job
Comment 5 Adam Williamson 2013-12-06 17:40:31 EST
Jakub was planning to push a build next week with fixes for other issues as well, which is why he hadn't done the update yet. For Fedora 20 release purposes, the key question is whether we've built something:

a) affected by this bug
b) which is an important component
c) since 2013-11-10

the stuff from c#4 ought to help answer that, I guess.
Comment 6 Jakub Jelinek 2013-12-06 17:47:36 EST
If you don't install the debuginfo rpms, but rpm2cpio | cpio -id them somewhere,
for eu-readelf -wi to work properly right now you have to always cd into the directory that contains some *.debug file and then run eu-readelf -wi *.debug
otherwise the relative paths to the .dwz file won't work.

And, you want to look for __unguarded_partition_pivot (the buggy inline function), either in DW_AT_name of DW_TAG_inlined_subroutine or perhaps also DW_TAG_subprogram).
Comment 7 Jakub Jelinek 2013-12-06 17:57:27 EST
Ah, though usually DW_TAG_inlined_subroutine will not have DW_AT_name attribute, but DW_AT_abstract_origin and the ultimate abstract origin will have that attribute.  Perhaps look at eu-readelf -ws instead, i.e.
rpm2cpio foobar*debuginfo*.rpm | cpio -id
find usr/lib/debug -type f | xargs eu-readelf -ws \
| grep __unguarded_partition_pivot
If you get any hits, then investigate more carefully with eu-readelf -wi.
Comment 8 Andy Lutomirski 2013-12-06 18:02:51 EST
The current F20 build of libstdc++ is affected (the testcases upstream fail).

eu-readelf -wi doesn't work for me ("i" isn't recognized) on f19's eu-readelf.  Do I need a newer version?  Do you mean -winfo?

For what it's worth, plain old std::sort calls __introsort_loop, which calls __unguarded_partition_pivot.  That being said (unless I messed up) there are no lists of length 7 that cause std::sort to overrun its input.
Comment 9 Andy Lutomirski 2013-12-06 18:40:56 EST
std::sort and __unguarded_partition_pivot may both be okay.  Comment #12 upstream suggests that it's only __unguarded_partition_pivot as called by __introselect that's wrong.
Comment 10 Mike Ruckman 2013-12-09 13:08:44 EST
Discussed in 2013-12-09 Blocker Review meeting [1]. It was voted to punt as not yet having sufficient information: we have a list of all packages built with affected gcc, but we do not yet know which contain the affected function(s). we will try to come up with a precise list and then re-evaluate.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-09/
Comment 11 Adam Williamson 2013-12-10 13:22:16 EST
Did we get anywhere beyond 'list of all packages built with affected gcc' in assessing the impact of this? I did a dumb bugzilla search and google site:bugzilla.redhat.com search for '__unguarded_partition_pivot' and 'unguarded_partition_pivot' and found nothing but this bug.
Comment 12 Robyn Bergeron 2013-12-11 05:07:44 EST
Blindly in the dark...

Looks like maybe qt is affected - (maybe not?)
https://bugreports.qt-project.org/browse/QTBUG-35058

Also:
kde-workspace
http://lists.kde.org/?l=kde-commits&m=138505708217421&w=2
http://lists.kde.org/?l=kde-commits&m=138506026531232&w=2


Also: It looks like the octave folks have this issue as well - it's not in the list of packages built with affected gcc, so not sure what that means. http://savannah.gnu.org/bugs/?40436#comment39 may be worth a gander
Comment 13 Matthew Miller 2013-12-11 11:44:36 EST
This is the list of packages referred to above: http://paste.fedoraproject.org/59955/38650848/raw/

anaconda
apr
apr-util
arm-boot-config
bind
blobby
bowtie
calligra
cinnamon
cinnamon-control-center
cinnamon-desktop
cinnamon-settings-daemon
code-editor
control-center
corebird
cups
cups-filters
devtodo2
dhcp
dnssec-trigger
docker-io
dracut
enlightenment
eyesight
foomatic
freeradius
gcc
gcompris
gimp
gimp-separate+
glabels
gloox
glusterfs
gnome-online-miners
gnome-settings-daemon
gnome-software
gnutls
golang-github-syndtr-gocapability
gq
gromacs
gssntlmssp
gstreamer1-plugins-bad-free
guacamole-server
highlight
hplip
httpd
ipsec-tools
kate
kdelibs
kdepimlibs
kde-workspace
krazy2
krb5
kscreen
lasso
libdrm
libfm
libhocr
librcc
libreoffice
libtopology
lightdm
lockdev
luajit
lxlauncher
lxpanel
mariadb
mate-desktop
mate-dialogs
mate-file-manager
mate-window-manager
menu-cache
mesa
mingw-qt5-qtbase
mingw-qt5-qtdeclarative
mingw-qt5-qttools
mongodb
muffin
MySQL-python
ncmpcpp
nemo
nemo-extensions
NetworkManager
nfs-ganesha
nfs-utils
nss
opencv
openssh
openssl
PackageKit
pcl
pcmanfm
phonon
phonon-backend-gstreamer
php-pecl-http
php-pecl-raphf
pidgin-sipe
pki-core
pki-tps
pocl
policycoreutils
ppl
printrun
pulseaudio
python-rhsm
python-schedutils
qt
qt3
qt5-qtbase
qt5-qtconfiguration
qt5-qtwebkit
samba
sddm
sdformat
SDL2_mixer
SFML
Singular
spring
stalonetray
strongswan
subscription-manager
system-config-printer
systemd
thunderbird-lightning
unittest-cpp
upower
varnish
vdsm
voms
vzctl
webkitgtk3
wmdocker
x2goserver
xorg-x11-server
xsettings-kde
xulrunner
znc
Comment 14 Matthew Miller 2013-12-11 13:01:28 EST
So I downloaded and unpacked the source to all of the above, and grepped for std::nth_element. It occurs in 


libreoffice
opencv
pcl
qt5-qtbase
Comment 15 Kevin Kofler 2013-12-11 13:07:45 EST
Indeed, according to QTBUG-35058, the use of nth_element was newly introduced in Qt 5, so Qt 4 should NOT be affected. (Crossing fingers.)

qt5-qtbase IS hit (see QTBUG-35058), but it is not a release-critical package. It can be fixed in an update (and will get updated soon anyway). I'd be more worried about libreoffice and opencv.
Comment 16 Mike Ruckman 2013-12-11 13:16:49 EST
Discussed in 2013-12-11 Blocker Review Meeting [1]. Voted as an RejectedBlocker. No critical packages are affected. The affected packages don't seem to be crashing frequently. Will be fixed in updates. 

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-11/
Comment 17 Kevin Kofler 2013-12-11 13:31:44 EST
LibreOffice is not a critical package???
Comment 18 Matthew Miller 2013-12-11 15:19:00 EST
(In reply to Kevin Kofler from comment #17)
> LibreOffice is not a critical package???

Not in this particular, technical sense of the word "critical". I don't think there's any argument that it's not important overall.
Comment 19 Adam Williamson 2013-12-11 15:28:28 EST
if LO was crashing all over the place that'd be one thing, but it doesn't seem to be. I did try running it and messing around with it a lot.

as matt says, in this context 'critical' would be 'something you can't live without' - i.e. if this bug was causing frequent unpredictable blowups in boot / desktop start / run a browser kinda things. that doesn't seem to be the case.
Comment 20 Matthew Miller 2013-12-11 15:39:51 EST
Are there bugs filed for rebuilds of the packages which are (probably) affected? If no one else was planning to do that I can.
Comment 21 Peter Robinson 2013-12-11 15:49:37 EST
(In reply to Matthew Miller from comment #20)
> Are there bugs filed for rebuilds of the packages which are (probably)
> affected? If no one else was planning to do that I can.

Normally rel-eng or a proven packager would just step in and do it rather than screw about with bug reports where maintainers might miss or ignore it.
Comment 22 Matthew Miller 2013-12-11 15:58:57 EST
(In reply to Peter Robinson from comment #21)
> Normally rel-eng or a proven packager would just step in and do it rather
> than screw about with bug reports where maintainers might miss or ignore it.

In this case though it looks like we're looking for _post release_ updates, with the associated bodhi process and etc.... I just want to make sure it's covered.
Comment 23 Fedora Update System 2013-12-13 16:46:02 EST
gcc-4.8.2-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gcc-4.8.2-7.fc20
Comment 24 Fedora Update System 2013-12-13 16:47:17 EST
gcc-4.8.2-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gcc-4.8.2-7.fc19
Comment 25 Fedora Update System 2013-12-13 22:09:53 EST
Package gcc-4.8.2-7.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gcc-4.8.2-7.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23364/gcc-4.8.2-7.fc20
then log in and leave karma (feedback).
Comment 26 Fedora Update System 2013-12-16 02:09:11 EST
gcc-4.8.2-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Fedora Update System 2013-12-19 21:02:50 EST
gcc-4.8.2-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.