Description of problem: When trying to open gnome software the program crashes. Version-Release number of selected component: gnome-software-42.2-1.fc37 Additional info: reporter: libreport-2.17.1 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-gnome-org.gnome.Software-1991.scope cmdline: /usr/bin/gnome-software --gapplication-service crash_function: _mm_loadu_ps executable: /usr/bin/gnome-software journald_cursor: s=b6218b21d0bb4168b30d4fa0a9a35b3b;i=1870;b=46788920246f4145b4aba290cff0e264;m=c5b0031;t=5e0b27d7cfbba;x=5894359de1976bf kernel: 5.19.0-0.rc0.20220531git8ab2afa23bd1.8.fc37.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 _mm_loadu_ps at /usr/lib/gcc/x86_64-redhat-linux/12/include/f16cintrin.h:69 #1 float_to_half4_f16c at ../gsk/gl/fp16i.c:37 #2 rgba_to_half at ../gsk/gl/gskglrenderjob.c:995 #3 gsk_gl_render_job_visit_blurred_outset_shadow_node at ../gsk/gl/gskglrenderjob.c:2466 #4 gsk_gl_render_job_visit_node at ../gsk/gl/gskglrenderjob.c:3729 #7 gsk_gl_render_job_visit_transform_node at ../gsk/gl/gskglrenderjob.c:2055 #8 gsk_gl_render_job_visit_node at ../gsk/gl/gskglrenderjob.c:3766 #9 gsk_gl_render_job_render at ../gsk/gl/gskglrenderjob.c:4078 #10 gsk_gl_renderer_render at ../gsk/gl/gskglrenderer.c:310 #11 gsk_renderer_render at ../gsk/gskrenderer.c:467
Created attachment 1887149 [details] File: backtrace
Created attachment 1887150 [details] File: core_backtrace
Created attachment 1887151 [details] File: cpuinfo
Created attachment 1887152 [details] File: dso_list
Created attachment 1887153 [details] File: environ
Created attachment 1887154 [details] File: exploitable
Created attachment 1887155 [details] File: limits
Created attachment 1887156 [details] File: maps
Created attachment 1887157 [details] File: mountinfo
Created attachment 1887158 [details] File: open_fds
Created attachment 1887159 [details] File: proc_pid_status
Created attachment 1887160 [details] File: var_log_messages
Thanks for a bug report. This looks like a crash deep in the gtk4 drawing code, thus I move this there for further investigation.
*** Bug 2093673 has been marked as a duplicate of this bug. ***
Nathan, can you provide the output of `cat /proc/cpuinfo`? Thanks!
Never mind, I forgot abrt includes that info already (it's attached). GCC folks, can you take a look at this? After chatting about it, mclasen and I both don't see that GTK is doing anything wrong here. It checks that the CPU supports f16c before using f16c builtins, and this user's CPU *does* support f16c, as shown in the attached cpuinfo output. So what's going on? I wondered if the problem was our compiler flags - we don't set -march on Fedora builds - but then you'd think if that was the problem we'd get a failure at compile time, not run time?
I don't see any documentation for __builtin_cpu_supports ("f16c"), which could mean that it is not expected to work. In particular, it does not implement the full check (the OSXSAVE part). You could use <sys/platform/x86.h> and CPU_FEATURE_ACTIVE (F16C) instead, which is supposed to handle this corner case.
I assume it is https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gl/fp16i.c , but it is unclear with what gcc options it is compiled. -mf16c implies -mavx in GCC (since the support has been added in 2010), from the /proc/cpuinfo it looks like the CPU only supports f16c and not avx. Is that CPU really without AVX support, or just some bogus virtualization disabling random ISAs and leaving others around?
Jakub: that file specifically is compiled with -mf16c , see https://kojipkgs.fedoraproject.org//packages/gtk4/4.7.0/1.fc37/data/logs/x86_64/build.log step 199/1921. Good point about avx not being in /proc/cpuinfo. That's odd. That CPU definitely has AVX support: https://www.intel.com/content/www/us/en/products/sku/191045/intel-core-i79750h-processor-12m-cache-up-to-4-50-ghz/specifications.html says "Instruction Set Extensions: Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2". So I guess some kind of virtualization weirdness could be involved here, or possibly some kind of local configuration - a kernel boot option maybe? Nathan, are you running in a virtual machine? Can you post the output of `cat /proc/cmdline` and maybe attach the output of `journalctl -b` from a boot where you reproduce the problem? Thanks!
I note 'xsave' isn't in the cpuinfo output either, and there is a kernel option, `noxsave`, which disables xsave and avx. Nathan, is it possible you're booting with `noxsave`?
I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105920
(In reply to Adam Williamson from comment #19) > Jakub: that file specifically is compiled with -mf16c , see > https://kojipkgs.fedoraproject.org//packages/gtk4/4.7.0/1.fc37/data/logs/ > x86_64/build.log step 199/1921. > > Good point about avx not being in /proc/cpuinfo. That's odd. That CPU > definitely has AVX support: > https://www.intel.com/content/www/us/en/products/sku/191045/intel-core- > i79750h-processor-12m-cache-up-to-4-50-ghz/specifications.html says > "Instruction Set Extensions: Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2". > > So I guess some kind of virtualization weirdness could be involved here, or > possibly some kind of local configuration - a kernel boot option maybe? > Nathan, are you running in a virtual machine? Can you post the output of > `cat /proc/cmdline` and maybe attach the output of `journalctl -b` from a > boot where you reproduce the problem? Thanks! Here is the output of the cat /proc/cmdline command: cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.19.0-0.rc1.20220610git874c8ca1e60b.18.fc37.x86_64 root=UUID=23c7755a-55b9-4d5e-9dd7-a6d016a75b84 ro rootflags=subvol=root rhgb quiet And below I also leave you the output of the journalctl -b command: giu 13 13:23:50 fedora kernel: Linux version 5.19.0-0.rc1.20220610git874c8ca1e6> giu 13 13:23:50 fedora kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.> giu 13 13:23:50 fedora kernel: Disabled fast string operations giu 13 13:23:50 fedora kernel: ------------[ cut here ]------------ giu 13 13:23:50 fedora kernel: XSAVE consistency problem, dumping leaves giu 13 13:23:50 fedora kernel: WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xs> giu 13 13:23:50 fedora kernel: Modules linked in: giu 13 13:23:50 fedora kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-0> giu 13 13:23:50 fedora kernel: RIP: 0010:fpu__init_system_xstate+0x7cf/0xa97 giu 13 13:23:50 fedora kernel: Code: 5c 1e d8 fe e8 4f 39 43 fd 41 39 c5 74 20 > giu 13 13:23:50 fedora kernel: RSP: 0000:ffffffffb3003e20 EFLAGS: 00010082 ORIG> giu 13 13:23:50 fedora kernel: RAX: 0000000000000029 RBX: 0000000000000040 RCX:> giu 13 13:23:50 fedora kernel: RDX: 0000000000000002 RSI: ffffffffb2828f59 RDI:> giu 13 13:23:50 fedora kernel: RBP: 0000000000000007 R08: 0000000000000003 R09:> giu 13 13:23:50 fedora kernel: R10: 0000000000000001 R11: 0000000000000000 R12:> giu 13 13:23:50 fedora kernel: R13: 0000000000000000 R14: 0000000000000340 R15:> giu 13 13:23:50 fedora kernel: FS: 0000000000000000(0000) GS:ffffffffb39fd000(> giu 13 13:23:50 fedora kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 giu 13 13:23:50 fedora kernel: CR2: ffff888000094100 CR3: 0000000071c74000 CR4:> giu 13 13:23:50 fedora kernel: Call Trace: giu 13 13:23:50 fedora kernel: <TASK> giu 13 13:23:50 fedora kernel: ? fpu__init_system+0x149/0x177 giu 13 13:23:50 fedora kernel: ? early_cpu_init+0x330/0x35b lines 1-23...skipping... giu 13 13:23:50 fedora kernel: Linux version 5.19.0-0.rc1.20220610git874c8ca1e60b.18.fc37.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1), GNU ld version 2.38-14.fc37) #1 SMP PR> giu 13 13:23:50 fedora kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.19.0-0.rc1.20220610git874c8ca1e60b.18.fc37.x86_64 root=UUID=23c7755a-55b9-4d5e-9dd7-a6d016a75b84 ro rootflags=subvol=root rhgb quiet giu 13 13:23:50 fedora kernel: Disabled fast string operations giu 13 13:23:50 fedora kernel: ------------[ cut here ]------------ giu 13 13:23:50 fedora kernel: XSAVE consistency problem, dumping leaves giu 13 13:23:50 fedora kernel: WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:606 fpu__init_system_xstate+0x7cf/0xa97 giu 13 13:23:50 fedora kernel: Modules linked in: giu 13 13:23:50 fedora kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-0.rc1.20220610git874c8ca1e60b.18.fc37.x86_64 #1 giu 13 13:23:50 fedora kernel: RIP: 0010:fpu__init_system_xstate+0x7cf/0xa97 giu 13 13:23:50 fedora kernel: Code: 5c 1e d8 fe e8 4f 39 43 fd 41 39 c5 74 20 80 3d b5 d4 77 ff 00 75 a8 48 c7 c7 10 b8 82 b2 c6 05 a5 d4 77 ff 01 e8 c0 20 25 fe <0f> 0b eb 91 8b 44 24 08 48 8b 3d 0f 1e d8 fe 31 f6 44 89 2d 16> giu 13 13:23:50 fedora kernel: RSP: 0000:ffffffffb3003e20 EFLAGS: 00010082 ORIG_RAX: 0000000000000000 giu 13 13:23:50 fedora kernel: RAX: 0000000000000029 RBX: 0000000000000040 RCX: 0000000000000000 giu 13 13:23:50 fedora kernel: RDX: 0000000000000002 RSI: ffffffffb2828f59 RDI: 00000000ffffffff giu 13 13:23:50 fedora kernel: RBP: 0000000000000007 R08: 0000000000000003 R09: 0000000000000000 giu 13 13:23:50 fedora kernel: R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 giu 13 13:23:50 fedora kernel: R13: 0000000000000000 R14: 0000000000000340 R15: 0000000000000100 giu 13 13:23:50 fedora kernel: FS: 0000000000000000(0000) GS:ffffffffb39fd000(0000) knlGS:0000000000000000 giu 13 13:23:50 fedora kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 giu 13 13:23:50 fedora kernel: CR2: ffff888000094100 CR3: 0000000071c74000 CR4: 00000000000406a0 giu 13 13:23:50 fedora kernel: Call Trace: giu 13 13:23:50 fedora kernel: <TASK> giu 13 13:23:50 fedora kernel: ? fpu__init_system+0x149/0x177 giu 13 13:23:50 fedora kernel: ? early_cpu_init+0x330/0x35b giu 13 13:23:50 fedora kernel: ? setup_arch+0x44/0xcba giu 13 13:23:50 fedora kernel: ? slab_is_available+0x5/0x20 giu 13 13:23:50 fedora kernel: ? security_add_hooks+0x63/0x89 giu 13 13:23:50 fedora kernel: ? start_kernel+0x79/0x995 giu 13 13:23:50 fedora kernel: ? load_ucode_bsp+0x3a/0x100 giu 13 13:23:50 fedora kernel: ? secondary_startup_64_no_verify+0xe5/0xeb giu 13 13:23:50 fedora kernel: </TASK> giu 13 13:23:50 fedora kernel: irq event stamp: 0 giu 13 13:23:50 fedora kernel: hardirqs last enabled at (0): [<0000000000000000>] 0x0 giu 13 13:23:50 fedora kernel: hardirqs last disabled at (0): [<0000000000000000>] 0x0 giu 13 13:23:50 fedora kernel: softirqs last enabled at (0): [<0000000000000000>] 0x0 giu 13 13:23:50 fedora kernel: softirqs last disabled at (0): [<0000000000000000>] 0x0 giu 13 13:23:50 fedora kernel: ---[ end trace 0000000000000000 ]--- giu 13 13:23:50 fedora kernel: CPUID[0d, 00]: eax=00000007 ebx=00000340 ecx=00000340 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 01]: eax=00000003 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 02]: eax=00000100 ebx=00000240 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 03]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 04]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 05]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 06]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 07]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 08]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 09]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0a]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0b]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0c]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0d]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0e]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 0f]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 10]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 11]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 12]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 13]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 14]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 15]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 giu 13 13:23:50 fedora kernel: CPUID[0d, 16]: eax=00000000 ebx=00000000 ecx=00000000 edx=000000
(In reply to Nathan from comment #22) > giu 13 13:23:50 fedora kernel: Disabled fast string operations > giu 13 13:23:50 fedora kernel: ------------[ cut here ]------------ > giu 13 13:23:50 fedora kernel: XSAVE consistency problem, dumping leaves > giu 13 13:23:50 fedora kernel: WARNING: CPU: 0 PID: 0 at > arch/x86/kernel/fpu/xs> > giu 13 13:23:50 fedora kernel: Modules linked in: > giu 13 13:23:50 fedora kernel: CPU: 0 PID: 0 Comm: swapper Not tainted > 5.19.0-0> > giu 13 13:23:50 fedora kernel: RIP: 0010:fpu__init_system_xstate+0x7cf/0xa97 This is very suspicious and points to a serious firmware or kernel bug (if no virtualization is involved). Fixing that will likely improve system performance measurably because many common string functions will run something like 20% to 30% faster.
Agreed, let's kick to kernel for now. Nathan, can you see if the bug still happens if you boot a stable 5.17 or 5.18 kernel? Can you also check if there are any firmware updates available for the system? Thanks!
ran tests with the 5.18 and 5.17 kernel without encountering any problems. I checked whether firmware updates are available, but there are none at the moment. I guess we can assume at this point that it is a kernel-level problem.
Yup, sure sounds like it. Justin, any ideas? Nathan, new 5.19 snapshots will appear in Rawhide fairly often, so if you can check them as they arrive and see if that gets resolved that'd be great. Sometimes stuff gets fixed upstream without us needing to do anything. You could also report this to upstream kernel bugzilla or LKML if you feel comfortable doing that!