Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2272758
| Summary: | Illegal instruction errors in libQt6Core | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jerry James <loganjerry> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 40 | CC: | agurenko, awilliam, code, danielsvpeter, dmalcolm, fedora, fweimer, gilbert.fernandes, jakub, jgrulich, jlaw, josmyers, jwakely, kde-sig, kparal, mcermak, mpolacek, msebor, nickc, nixuser, oncaphillis, rhgadsdon, robatino, samoht0-bugzilla, scorreia, seda18, shawn, sipoyare, thiago, villemurclement, waltertuttle1964, zuhhaga |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | gcc-14.0.1-0.15.fc40 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-04-14 17:13:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2187794 | ||
|
Description
Jerry James
2024-04-02 20:27:19 UTC
# kwrite Illegal instruction (core dumped) # kate Illegal instruction (core dumped) # make xconfig make[2]: *** [scripts/kconfig/Makefile:56: xconfig] Illegal instruction (core dumped) make[1]: *** [/usr/src/linux-6.8.2/Makefile:689: xconfig] Error 2 make: *** [Makefile:240: __sub-make] Error 2 # grub-customizer - runs correctly... I did a rebuild hoping an updated GCC might make a difference. The build is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=115812048 Can you please try it and test whether it makes any difference? No difference. # rpm -qa |grep qt6-qtbase qt6-qtbase-common-6.6.2-7.fc40.noarch qt6-qtbase-6.6.2-7.fc40.x86_64 qt6-qtbase-gui-6.6.2-7.fc40.x86_64 qt6-qtbase-ibase-6.6.2-7.fc40.x86_64 qt6-qtbase-mysql-6.6.2-7.fc40.x86_64 qt6-qtbase-odbc-6.6.2-7.fc40.x86_64 qt6-qtbase-postgresql-6.6.2-7.fc40.x86_64 qt6-qtbase-devel-6.6.2-7.fc40.x86_64 Test: $ kwrite Illegal instruction (core dumped) $ startplasma Illegal instruction (core dumped) The VUF of qt6-qtbase is the same for the 'good' version of F40 (last week..) as for the 'broken' version (now..). 6.6.2-6.fc40 Some of the correspondence suggested SDDM might be the cuplrit?, and this _has_ changed 'good F40' sddm-kcm-6.0.2-1.fc40.x86_64 sddm-wayland-plasma-6.0.2-1.fc40.noarch sddm-0.21.0-4.fc40.x86_64 'broken F40' sddm-wayland-plasma-6.0.3-1.fc40.noarch sddm-kcm-6.0.3-1.fc40.x86_64 sddm-breeze-6.0.3-1.fc40.noarch I had tried to 'downgrade' (revert) these, but got: Package sddm-wayland-plasma of lowest version already installed, cannot downgrade it. Package sddm-kcm of lowest version already installed, cannot downgrade it. Package sddm-breeze of lowest version already installed, cannot downgrade it. Dependencies resolved. Nothing to do. *** Bug 2262640 has been marked as a duplicate of this bug. *** I reported this issue to upstream as I have no idea what might be the issue here. Qt bug: https://bugreports.qt.io/browse/QTBUG-123965 According to Qt dev, this is a GCC bug. See the Qt bug for analysis. Reassigning to gcc. Reported upstream to GCC at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576 If GCC is the culprit, this is the difference between working and broken versions of F40 (from /proc/version): Working F40: (gcc (GCC) 14.0.1 20240316 (Red Hat 14.0.1-0), GNU ld version 2.41-34.fc40) Broken F40: (gcc (GCC) 14.0.1 20240328 (Red Hat 14.0.1-0), GNU ld version 2.41-34.fc40) According to GCC bugzilla, this has now been fixed: Status: RESOLVED FIXED This bug is marked as [NEEDINFO]. What information is needed? I am affected by this bug, so I would be able to provide some information. Some bug reports from ABRT with affected applications: https://bugzilla.redhat.com/buglist.cgi?quicksearch=AESHashSeed%3A%3Astate1%28%29%20SIGILL&list_id=13436572 Proposed as a Blocker and Freeze Exception for 40-final by Fedora user genodeftest using the blocker tracking app because: For some users (with old CPUs), all applications that use QT6's qhash module crash whenever using that module. For users of a QT-based desktop, this would make the system unusable. In a GNOME desktop, some applications keep crashing every few minutes, including Tracker miners (because GStreamer uses the qhash module in some tracker miners). This causes about 50 crash notifications per hour (!) on some systems, flooding coredumpctl and ABRT and making the system slower. PS: Please note that this only affects old CPUs, probably only x86_64 CPUs without AVX. I have no clue how large the user base with those CPUs is to Fedora and whether that justifies blocking the F40 final. If this blocker is not accepted, can you please make sure to note it under "common F40 issues"? (In reply to Fedora Blocker Bugs Application from comment #11) > can you please make sure to note it under "common F40 issues"? I've created a proposal for "Common F40 issues": https://discussion.fedoraproject.org/t/on-old-cpus-many-applications-are-crashing-especially-qt6-based-applications/112407 *** Bug 2273703 has been marked as a duplicate of this bug. *** So, uh, there's a hell of a lot of acronyms in the upstream discussion, and I am getting lost between my AVX, VEX, EVEX, and VAES...the fact that the problematic instruction is 'vaesenc' and VAES is listed as a fairly recent innovation seems pretty concerning, but I...*think*..."The VEX versions can be used without AVX-512 support" (from https://en.wikipedia.org/wiki/AVX-512 ) means you don't actually need a CPU with AVX-512 "VAES" support for the 'vaesenc' instruction to work, only a CPU with AVX support? Confusing! The only affected person who posted CPU info so far has a Pentium Silver N5000, which is one of the fairly recent extremely low-end CPUs Intel released without AVX support, I believe - https://www.techpowerup.com/cpu-specs/pentium-silver-n5000.c3277 . Intel appears to have made these at least as late as 2020 - https://news.ycombinator.com/item?id=24578591 - and someone in that thread talks about "the unfortunate 6.5% of Steam users without AVX1", which seems like a concerning number. As of the March 2024 numbers at https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam , 97.13% of systems have AVX, 98.39% have AES, so the no-AVX percentage would appear to be down to 2.87% . aesenc/vaesenc instruction actually depending on the arguments and VEX/EVEX encoding is either:
aesenc xmm1, xmm2/m128 AES ISA
vaesenc xmm1, xmm2, xmm3/m128 AES+AVX ISAs (if VEX encoded)
vaesenc xmm1, xmm2, xmm3/m128 VAES+AVX512VL ISAs (if EVEX encoded)
vaesenc ymm1, ymm2, ymm3/m256 VAES ISA (if VEX encoded)
vaesenc ymm1, ymm2, ymm3/m256 VAES+AVX512VL ISAs (if EVEX encoded)
vaesenc zmm1, zmm2, zmm3/m512 VAES+AVX512F ISAs (EVEX encoded)
I'll build fixed gcc soon, but will need support for requesting it as F40 exception or blocker.
Plus one will need to rebuild whatever library is affected by that (i.e. the library/libraries which have vaesenc instruction
even when they were just compiled with requesting AES ISA (-misa or #pragma GCC target ("aes") etc.).
Jakub: yes, I saw that table, but that is waaaaaaay too complicated for me. Can you dumb it down a bit? In terms of things I can find accurately explained on wikipedia, what CPUs are affected by this? Is it really just "x86_64 CPUs without AVX" or is it more complicated than that? Thanks a lot! This is already proposed as a blocker and FE, voting is ongoing; having the most accurate info about affected systems would be very helpful to that. if it's a blocker we are pretty much stuck with a slip to fix it, since go/no-go is tomorrow and it takes 21 hours to build gcc :( On x86_64, we can assume the MMX, SSE, and SSE2 instruction set architecture (ISA) extensions are present; no x86_64 hardware without them was ever sold. We can also assume that on i686 as well now, since i686 is multilib-only in Fedora and therefore our i686 packages must be running on 64-bit capable hardware. We *cannot* assume support for any later ISA extensions (SSSE3, SSE4.2, AVX, AVX2, any flavor of AVX512, POPCNT, RDRAND, or any of a number of more obscure extensions). Software can use them where available, but applications need to do runtime dispatch and not crash where they are absent. Note that RHEL9 started requiring a baseline of x86_64-v2, which brings in several more ISA extensions leading up to but not including AVX, but Fedora made no such change. VEX is a new instruction coding prefix introduced with AVX. It’s not only used for AVX, but also provides new encodings for all the pre-existing instructions. However, if we can’t assume AVX, we can’t assume VEX-encoded SSE2 instructions are OK either. EVEX is yet another instruction coding prefix introduced to support the needs of AVX-512. Does that help? No, not really. Abstracts don't help us much. I know there are lots of instruction sets and lots of combinations of CPUs that have or do not have some of them. We are more interested in concrete real-world specifics about this bug. Is the set of real-world CPUs affected by this bug equivalent to the set of real-world CPUs that do not have AVX, or is it more complicated than that? Well, the VEX-encoding is a bit of a red herring, because hardware AES support (AES-NI) is not in the x86_64 baseline, regardless of which instruction coding scheme is used. I’m not sure if there were ever any CPUs with AES-NI but not AVX, or AVX but not AES-NI, but there are certainly x86_64 CPUs with neither. There were multiple issues fixed by my commit, but most of them just theoretical (I'm not aware of any CPUs which would have VAES ISA support but wouldn't have AES). So, assuming there are none even in the future, all the PR fixed was incorrectly using the AES+AVX needing instruction in code which requested just AES. So, that means misbehavior on all CPUs which do have AES but don't have AVX. Don't know how to get a list of such CPUs, guess that information e.g. for Intel is burried in the ark.intel.com database, but not really sure how to query that. Looking at the GCC supported -march= CPUs which do have -maes but don't have -mavx it seems it is goldmont, goldmont-plus, tremont and lujiazui. Thanks a lot. Another complicating factor...it looks like this is more complicated than just 'rebuild qt6-qtbase with fixed gcc'. qt6-qtbase itself has, I think, never been built with the affected gcc for F40, it was last built with gcc 14.0.1-0.7.fc40 on 2024-03-11, and that should not have been affected per comment #8 and my own research. So, what is it that got miscompiled? At first I thought sddm, but no, that was last built with gcc 14.0.1-0.7.fc40 too. Plus, the discourse thread says node and npm are affected, which kinda looks like something outside of the kde/qt ecosystem is also affected. Do we have any good way to figure out what we actually need to recompile to fix this? I *think* the bug arrived in Fedora with gcc-14.0.1-0.12.fc40 , so only things built with that gcc or later should be affected... The bug was there since the https://gcc.gnu.org/r14-104 commit back in April 2023, so all of gcc-14.0.{0,1}* are affected. ohh, jeez, I may have flubbed 2023 vs. 2024 :D I found that commit but completely misread the date on it, d'oh. So...maybe we do only need to rebuild qt6-qtbase to fix KDE, but probably something else is causing the node/npm crash, I guess possibly nodejs20 also is affected? Our affected CPU from discourse is a Pentium Silver N5000, which is indeed a Goldmont Plus chip. Wikipedia lists the CPUs for each of those platforms at https://en.wikipedia.org/wiki/Goldmont , https://en.wikipedia.org/wiki/Goldmont_Plus , https://en.wikipedia.org/wiki/Tremont_(microarchitecture) . lujiazui is a Zhaoxin platform, apparently - https://en.wikichip.org/wiki/zhaoxin/microarchitectures/lujiazui , sold only in the Chinese market (no idea how many folks using one of those might want to run Fedora). (In reply to Adam Williamson from comment #23) > ohh, jeez, I may have flubbed 2023 vs. 2024 :D I found that commit but > completely misread the date on it, d'oh. So...maybe we do only need to > rebuild qt6-qtbase to fix KDE, but probably something else is causing the > node/npm crash, I guess possibly nodejs20 also is affected? The issue with nodejs and npm has already been fixed here: https://bugzilla.redhat.com/show_bug.cgi?id=2273542 aha, OK, so that one wasn't actually this bug. thanks. AESNI was first released with Nehalem (a.k.a. "Intel Core i3/i5/i7" without "generation" anywhere) back in 2008. AVX only came with Sandy Bridge ("Intel Core Second Generation" in 2010), but is missing on all processors sold under the Atom, Pentium and sometimes Centrino brands. As was seen, some of those do have AESNI -- seems like it's always present, except for certain SKUs meant for some export markets, for some reason.
The CPU cores that power Atoms now have support for AVX, but there hasn't been a new Atom-branded product with it yet. They're only present as E-cores in hybrid client systems and will be in the E-core line of Xeon server processors.
(In reply to Thiago Macieira from comment #26) > AESNI was first released with Nehalem (a.k.a. "Intel Core i3/i5/i7" without > "generation" anywhere) back in 2008. AVX only came with Sandy Bridge ("Intel > Core Second Generation" in 2010), but is missing on all processors sold > under the Atom, Pentium and sometimes Centrino brands. As was seen, some of > those do have AESNI -- seems like it's always present, except for certain > SKUs meant for some export markets, for some reason. > > The CPU cores that power Atoms now have support for AVX, but there hasn't > been a new Atom-branded product with it yet. They're only present as E-cores > in hybrid client systems and will be in the E-core line of Xeon server > processors. Agreed, according to wikipedia: https://en.wikipedia.org/wiki/AES_instruction_set https://de.wikipedia.org/wiki/Advanced_Vector_Extensions Intel Westmere based processors have AES-NI, but no VAX. Except Celeron, Pentium, Core i3, Core i5-4XXM, that have no AES-NI. From my knowledge, this looks correct. I've got an old Core i3 530 (Clarkdale). Checked, no AES-NI. In some related bug, I sadly couldn't find currently, a Core i5 650 (Clarkdale) was mentioned. Which seems valid. (In reply to Adam Williamson from comment #14) > The only affected person who posted CPU info so far has a Pentium Silver > N5000 I have two relatively old devices, one affected, one not. * Affected: Intel Core i5-650. * Not affected: Intel Core i5-2450M (In reply to samoht0 from comment #27) > In some related bug, I sadly couldn't find currently, a Core i5 650 > (Clarkdale) was mentioned. Which seems valid. That was probably me in bug #2273703#c13. Feel free to ask for more details. I've posted `/proc/cpuinfo` of the affected device in https://discussion.fedoraproject.org/t/many-programs-crash-with-illegal-instruction-core-dumped/110509/33 (In reply to Ben Beasley from comment #19) > I’m not sure if there were ever any CPUs > with AES-NI but not AVX, or AVX but not AES-NI, but there are certainly > x86_64 CPUs with neither. There were CPUs with AES-NI but not AVX, e.g. my Intel Core i5-650. ARK's data: https://ark.intel.com/content/www/us/en/ark/products/43546/intel-core-i5-650-processor-4m-cache-3-20-ghz.html This bug is not related to AES-NI: Both CPUs I have support AES-NI, but only one of them is affected. Per comment #20 the bug *is* related to AES-NI: "So, that means misbehavior on all CPUs which do have AES but don't have AVX." (In reply to Adam Williamson from comment #21) > So, what is it that got miscompiled? At first I thought sddm On my machine (GNOME/Wayland desktop), I see the crash in qt6-qtbase's qhash, see bug #2273703. In my case this happens with different applications using that library, for example in plasma-browser-integration or gstreamer1 (pulled in by tracker-miners) or Okular. I do not have sddm installed. In the sddm bug (bug #2262640 ), the backtrace looks almost identical. (In reply to Adam Williamson from comment #29) > Per comment #20 the bug *is* related to AES-NI: "So, that means misbehavior > on all CPUs which do have AES but don't have AVX." Thanks for this correction! Some overview of the cpuinfo from affected people I could find: * Intel Pentium Silver N5030, see bug #2263309 and bug #2273703 * Intel Pentium Silver N5000, see bug #2272491 * Intel Celeron N5105, see bug #2262220 * Intel Core i5-650, see https://discussion.fedoraproject.org/t/many-programs-crash-with-illegal-instruction-core-dumped/110509/33 (mine) All of them have "aes", but not "avx" in the "Flags" field. *** Bug 2263309 has been marked as a duplicate of this bug. *** *** Bug 2272491 has been marked as a duplicate of this bug. *** *** Bug 2262220 has been marked as a duplicate of this bug. *** Note, while https://koji.fedoraproject.org/koji/taskinfo?taskID=116184755 is still building on s390x, on other arches it finished already, so if somebody wants to test and rebuild in local mock qt6-qtbase or whatever contains the vaesenc instead of aesenc instruction, it is possible. The problem occurs on all the Intel systems I have: From /proc/cpuinfo.. Intel(R) Atom(TM) x5-Z8350 13th Gen Intel(R) Core(TM) i7-1355U Intel(R) Xeon(R) CPU E5-2697 Intel(R) Xeon(R) CPU E3-1270 V2 Intel(R) Celeron(R) J4125 Intel(R) Celeron(R) J4115 Correction: The 13th Gen Intel(R) Core(TM) i7-1355U (HP Envy 17 2023) is _not_ affected by this particular bug. It will not boot into F40 plasma-wayland, and just displays a black screen with cursor, but that is a different issue, as far as I can tell.. Boots OK into plasma-x11.. Robert: the E5-2697 and E3-1270 V2 are both listed by Intel as having AVX support: https://www.intel.com/content/www/us/en/products/sku/75283/intel-xeon-processor-e52697-v2-30m-cache-2-70-ghz/specifications.html https://www.intel.com/content/www/us/en/products/sku/65727/intel-xeon-processor-e31270-v2-8m-cache-3-50-ghz/specifications.html It seems unlikely that they are really affected by this bug. How did you determine that they are? I think the most reliable thing to do would be to boot a desktop that is not broken by this (e.g. GNOME) and run an app that is (e.g. mediawriter), and check whether it actually crashes with a SIGILL error. Discussed in 2024-04-11 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-11/f40-final-go-no-go-meeting.2024-04-11-17.00.html . Accepted as a blocker on the basis that, while the range of affected CPUs is small, the fact that multiple people reported this issue indicates there are definitely folks who want to use the affected software on the affected CPUs, the effect is fatal for one release-blocking desktop (KDE), and this *is* hardware we intend to support. A friend pointed out this issue and I realized I have one of these low end CPUs mentioned around: in my case, I have an N5105, "Intel(R) Celeron(R) N5105 @ 2.00GHz" as per cpuinfo. No AVX here: # grep avx /proc/cpuinfo I tried to boot the Fedora-KDE-Live-x86_64-40_Beta-1.10.iso but it would not start the graphical interface, would show only a black screen. I went to the other terminal and a "dmesg" shows floods of the following message: [ 4383.232900] traps: drkonqi-coredum[366850] trap invalid opcode ip:7fb6f250ea9c sp:7ffc41c27338 error:0 in libQt6Core.so.6.6.2[7fb6f24b0000+3e7000] [ 4383.609189] traps: drkonqi-coredum[366873] trap invalid opcode ip:7fc5ed90ea9c sp:7ffd040b95b8 error:0 in libQt6Core.so.6.6.2[7fc5ed8b0000+3e7000] [ 4383.657746] traps: drkonqi-coredum[366874] trap invalid opcode ip:7f953630ea9c sp:7ffc356bd2f8 error:0 coredumpctl gdb confirms it's signal 4 ILL, so it's the issue being discussed here. I grabbed the gcc built from https://koji.fedoraproject.org/koji/taskinfo?taskID=116184755 as indicated by Jakub and rebuilt qt6-qtbase locally in mock, with the newer gcc. Copied over the rpms, installed in the problematic machine, restarted sddm, now I have a graphical interface, so it seems that gcc update will resolve the issue. Oh, hah, I just did the same and was about to ask people to test. If anyone wants to confirm, please update with the qt6 packages from https://adamwill.fedorapeople.org/qt6-2272758/ and see if things work better now. thanks! sadly the gcc build restarted because a koji box died when it was nearly done, so we get to wait another day before we can run an official build :( My previous response did not post, for some reason.. I tested again, and the Xeon system issues were not due to this particular issue. Apologies for the confusion. Tested with the new version of qt6-2272758 etc and can confirm that this fixes the problem, on the three affected systems: Intel(R) Atom(TM) x5-Z8350 Intel(R) Celeron(R) J4125 Intel(R) Celeron(R) J4115 Thanks.. In f41 https://bodhi.fedoraproject.org/updates/FEDORA-2024-27a881e1ce gcc-14.0.1-0.14.fc41 is now in the buildroots, so qt6-qtbase can be rebuilt there. As for the f40 build, koji has been rebooted and s390x build restarted from scratch, so it will take still a while. And I'd prefer if for the f40 errata https://koji.fedoraproject.org/koji/taskinfo?taskID=116228449 gcc-14.0.1-0.15.fc40 was used instead, that fixes a libstdc++ ABI problem and it is expected to finish roughly at the same time as gcc-14.0.1-0.14.fc40. Thank you Jakub. qt6-qtbase for Rawhide is submitted here: https://koji.fedoraproject.org/koji/taskinfo?taskID=116256467 I don't know whether I'll be around once the f40 build of gcc is done, in any case, whoever can just merge qtbase rawhide into f40 and do the rebuild. FEDORA-2024-17bcbff3cf (qt6-qtbase-6.7.0-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-17bcbff3cf FEDORA-2024-17bcbff3cf (qt6-qtbase-6.7.0-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. I can do the build and update when gcc -15 is done. It's still running ATM... (In reply to Adam Williamson from comment #41) > Oh, hah, I just did the same and was about to ask people to test. If anyone > wants to confirm, please update with the qt6 packages from > https://adamwill.fedorapeople.org/qt6-2272758/ and see if things work better > now. thanks! That build fixes the issue for me, thanks! The crash is not happening any more when starting Okular, or plasma-browser-integration, or tracker miners (through GStreamer), or `mediawriter`. For mediawriter I confirmed (using gdb breakpoint) that it actually calls the `aeshash128` function immediately at startup. (In reply to Adam Williamson from comment #41) > Oh, hah, I just did the same and was about to ask people to test. If anyone > wants to confirm, please update with the qt6 packages from > https://adamwill.fedorapeople.org/qt6-2272758/ and see if things work better > now. thanks! I tried this build on my Pentium SIlver N5000 and 'mediawriter' for example works again. Thanks! https://koji.fedoraproject.org/koji/taskinfo?taskID=116228449 gcc-14.0.1-0.15.fc40 build finished and testing results look good. So feel free to tag it into a side-tag and build qt6-qtbase in there + whatever else is needed. Doing that now. FEDORA-2024-ad7a6c3c89 (gcc-14.0.1-0.15.fc40 and qt6-qtbase-6.6.2-7.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ad7a6c3c89 FEDORA-2024-ad7a6c3c89 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-ad7a6c3c89` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ad7a6c3c89 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. Applied this, and can confirm that it fixes the 'Illegal instruction (core dumped)' problem. Thanks.. FEDORA-2024-ad7a6c3c89 (gcc-14.0.1-0.15.fc40 and qt6-qtbase-6.6.2-7.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. *** Bug 2267057 has been marked as a duplicate of this bug. *** *** Bug 2276483 has been marked as a duplicate of this bug. *** |