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.)
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?
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.
For F19, gcc 4.8.2-1 went stable on 2013-10-29 03:36:44 , so anything built since then is potentially affected.
<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
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.
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).
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.
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.
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.
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/
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.
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
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
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
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.
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/
LibreOffice is not a critical package???
(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.
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.
Are there bugs filed for rebuilds of the packages which are (probably) affected? If no one else was planning to do that I can.
(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.
(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.
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
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
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).
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.
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.