Bug 2272758 - Illegal instruction errors in libQt6Core
Summary: Illegal instruction errors in libQt6Core
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 40
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 2262220 2262640 2263309 2267057 2272491 2273703 2276483 (view as bug list)
Depends On:
Blocks: F40FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2024-04-02 20:27 UTC by Jerry James
Modified: 2024-04-22 17:51 UTC (History)
32 users (show)

Fixed In Version: gcc-14.0.1-0.15.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-04-14 17:13:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 114576 0 P1 RESOLVED [14 regression] VEX-prefixed AES instruction without AVX enabled 2024-04-10 07:11:23 UTC
Qt Bug Tracker QTBUG-123965 0 Not Evaluated Reported SIGILL crash in qHash with GCC 14 2024-04-03 08:47:28 UTC

Description Jerry James 2024-04-02 20:27:19 UTC
Multiple users are reporting illegal instruction errors with libQt6Core in Fedora 40 Beta.  See:

- https://discussion.fedoraproject.org/t/many-programs-crash-with-illegal-instruction-core-dumped/110509
- https://discussion.fedoraproject.org/t/sddm-not-starting-after-rebase-to-kinoite-40/110019

As noted in the first link, src/corelib/tools/qhash.cpp seems to be implicated.  It contains functions that use AES and some vector instructions.  It appears that at least a few users have systems where the instructions in question are unavailable.

I myself am unaffected, just reporting what I am seeing on discussion.fedoraproject.org.

Reproducible: Always

Steps to Reproduce:
1. For the affected users, simply trying to use sddm or mediawriter is sufficient
2.
3.
Actual Results:  
Crashes due to SIGILL.

Expected Results:  
No crashes.

Comment 1 Robert Gadsdon 2024-04-03 00:16:22 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...

Comment 2 Jan Grulich 2024-04-03 07:28:50 UTC
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?

Comment 3 Robert Gadsdon 2024-04-03 08:02:22 UTC
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.

Comment 4 Jan Grulich 2024-04-03 08:35:41 UTC
*** Bug 2262640 has been marked as a duplicate of this bug. ***

Comment 5 Jan Grulich 2024-04-03 08:48:40 UTC
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

Comment 6 Jan Grulich 2024-04-03 16:59:57 UTC
According to Qt dev, this is a GCC bug. See the Qt bug for analysis.

Reassigning to gcc.

Comment 7 Thiago Macieira 2024-04-03 17:37:29 UTC
Reported upstream to GCC at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576

Comment 8 Robert Gadsdon 2024-04-03 18:27:27 UTC
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)

Comment 9 Robert Gadsdon 2024-04-10 06:56:14 UTC
According to GCC bugzilla, this has now been fixed:

Status: 	RESOLVED FIXED

Comment 10 Christian Stadelmann 2024-04-10 07:11:23 UTC
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

Comment 11 Fedora Blocker Bugs Application 2024-04-10 07:19:06 UTC
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"?

Comment 12 Christian Stadelmann 2024-04-10 07:42:54 UTC
(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

Comment 13 Jan Grulich 2024-04-10 08:02:33 UTC
*** Bug 2273703 has been marked as a duplicate of this bug. ***

Comment 14 Adam Williamson 2024-04-10 15:25:09 UTC
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% .

Comment 15 Jakub Jelinek 2024-04-10 15:39:53 UTC
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.).

Comment 16 Adam Williamson 2024-04-10 15:46:58 UTC
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 :(

Comment 17 Ben Beasley 2024-04-10 15:50:43 UTC
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?

Comment 18 Adam Williamson 2024-04-10 15:54:13 UTC
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?

Comment 19 Ben Beasley 2024-04-10 15:57:58 UTC
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.

Comment 20 Jakub Jelinek 2024-04-10 16:07:52 UTC
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.

Comment 21 Adam Williamson 2024-04-10 16:20:26 UTC
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...

Comment 22 Jakub Jelinek 2024-04-10 16:23:33 UTC
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.

Comment 23 Adam Williamson 2024-04-10 16:30:30 UTC
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).

Comment 24 seda18 2024-04-10 16:39:03 UTC
(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

Comment 25 Adam Williamson 2024-04-10 16:46:59 UTC
aha, OK, so that one wasn't actually this bug. thanks.

Comment 26 Thiago Macieira 2024-04-10 17:10:32 UTC
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.

Comment 27 samoht0 2024-04-10 17:26:32 UTC
(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.

Comment 28 Christian Stadelmann 2024-04-10 18:00:45 UTC
(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.

Comment 29 Adam Williamson 2024-04-10 18:04:51 UTC
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."

Comment 30 Christian Stadelmann 2024-04-10 18:09:02 UTC
(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!

Comment 31 Christian Stadelmann 2024-04-10 19:50:25 UTC
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.

Comment 32 Christian Stadelmann 2024-04-10 19:54:03 UTC
*** Bug 2263309 has been marked as a duplicate of this bug. ***

Comment 33 Christian Stadelmann 2024-04-10 19:54:53 UTC
*** Bug 2272491 has been marked as a duplicate of this bug. ***

Comment 34 Christian Stadelmann 2024-04-10 19:55:09 UTC
*** Bug 2262220 has been marked as a duplicate of this bug. ***

Comment 35 Jakub Jelinek 2024-04-11 07:31:55 UTC
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.

Comment 36 Robert Gadsdon 2024-04-11 08:45:58 UTC
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

Comment 37 Robert Gadsdon 2024-04-11 11:55:26 UTC
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..

Comment 38 Adam Williamson 2024-04-11 14:54:29 UTC
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.

Comment 39 Adam Williamson 2024-04-11 18:58:37 UTC
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.

Comment 40 Sergio Correia 2024-04-11 20:24:36 UTC
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.

Comment 41 Adam Williamson 2024-04-11 20:33:10 UTC
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 :(

Comment 42 Robert Gadsdon 2024-04-12 06:20:13 UTC
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..

Comment 43 Jakub Jelinek 2024-04-12 08:18:00 UTC
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.

Comment 44 Jan Grulich 2024-04-12 08:22:48 UTC
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.

Comment 45 Fedora Update System 2024-04-12 10:59:34 UTC
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

Comment 46 Fedora Update System 2024-04-12 12:30:24 UTC
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.

Comment 47 Adam Williamson 2024-04-12 15:31:47 UTC
I can do the build and update when gcc -15 is done. It's still running ATM...

Comment 48 Christian Stadelmann 2024-04-12 15:42:21 UTC
(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.

Comment 49 seda18 2024-04-12 17:57:28 UTC
(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!

Comment 50 Jakub Jelinek 2024-04-13 13:36:26 UTC
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.

Comment 51 Adam Williamson 2024-04-13 16:03:16 UTC
Doing that now.

Comment 52 Fedora Update System 2024-04-13 18:17:14 UTC
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

Comment 53 Fedora Update System 2024-04-14 02:06:02 UTC
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.

Comment 54 Robert Gadsdon 2024-04-14 08:29:16 UTC
Applied this, and can confirm that it fixes the 'Illegal instruction (core dumped)' problem.
Thanks..

Comment 55 Fedora Update System 2024-04-14 17:13:41 UTC
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.

Comment 56 Jan Grulich 2024-04-19 12:46:53 UTC
*** Bug 2267057 has been marked as a duplicate of this bug. ***

Comment 57 Jan Grulich 2024-04-22 17:51:57 UTC
*** Bug 2276483 has been marked as a duplicate of this bug. ***


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