Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Aurelien Jarno writes: > Hi, > > On 2022-09-26 09:45, Vasudev Kamath wrote: >> And post removing /usr/lib version of libc it seems to work fine and no >> crash is happening. >> >> └─(09:44:30 on master)──> expr >> >> 1 ↵ ──(Mon,Sep26)─┘ >> expr: missing operand >> Try 'expr --help' for more information. >> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ >> └─(09:44:39 on master)──> > > Thanks for all the details. It's great that your system is now fixed. Do > you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu? > I do not see any explanation from the glibc side. Did you attempt a > usrmerge migration that failed after moving some files, or do you think > it's unrelated? > I seriously did not have a clue why system was in this state. I had installed system back in 2019 and just keep updating. Also it was not just glibc, a whole bunch of packages were in this state and it took me a while to fix the entire system. (Had to write script to automate entire process). I don't remember me attempting to install usrmerge but not sure if it came via some dependency and failed to install. Feels weird why system was in such a state. Cheers, Vasudev
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Hi, On 2022-09-26 09:45, Vasudev Kamath wrote: > And post removing /usr/lib version of libc it seems to work fine and no > crash is happening. > > └─(09:44:30 on master)──> expr > > 1 ↵ ──(Mon,Sep26)─┘ > expr: missing operand > Try 'expr --help' for more information. > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:44:39 on master)──> Thanks for all the details. It's great that your system is now fixed. Do you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu? I do not see any explanation from the glibc side. Did you attempt a usrmerge migration that failed after moving some files, or do you think it's unrelated? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Vasudev Kamath writes: > Post installation of usrmerge this output is changed > > └─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6 > > 1 ↵ ──(Mon,Sep26)─┘ > -rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6 > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6 > > ──(Mon,Sep26)─┘ > -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 > /usr/lib/x86_64-linux-gnu/libc.so.6 > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:37:25 on master)──> ls -ld /lib > > ──(Mon,Sep26)─┘ > drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:38:14 on master)──> > > So looks like my system is not in sane state. Do I need to just delete > /usr/lib/ libc and try this?. From objdump -p output it looks like /lib version is the 2.35 3 0x00 0x069691b2 GLIBC_2.32 GLIBC_2.31 34 0x00 0x069691b3 GLIBC_2.33 GLIBC_2.32 35 0x00 0x069691b4 GLIBC_2.34 GLIBC_2.33 36 0x00 0x069691b5 GLIBC_2.35 GLIBC_2.34 37 0x00 0x0963cf85 GLIBC_PRIVATE GLIBC_2.35 and /usr/lib version is 2.34 GLIBC_2.30 33 0x00 0x069691b2 GLIBC_2.32 GLIBC_2.31 34 0x00 0x069691b3 GLIBC_2.33 GLIBC_2.32 35 0x00 0x069691b4 GLIBC_2.34 GLIBC_2.33 36 0x00 0x0963cf85 GLIBC_PRIVATE GLIBC_2.34 And post removing /usr/lib version of libc it seems to work fine and no crash is happening. └─(09:44:30 on master)──> expr 1 ↵ ──(Mon,Sep26)─┘ expr: missing operand Try 'expr --help' for more information. ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:44:39 on master)──> Cheers, Vasudev
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Vasudev Kamath writes: > > └─(09:09:40 on master)──> ls -ld /lib > > ──(Mon,Sep26)─┘ > drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6 > > ──(Mon,Sep26)─┘ > -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6 > ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ > └─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 > > ──(Mon,Sep26)─┘ > -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 > /usr/lib/x86_64-linux-gnu/libc.so.6 > ┌─(~/.emacs.d)─ > > Is it that if I install usrmerge and then upgrade libc it should work? Post installation of usrmerge this output is changed └─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6 1 ↵ ──(Mon,Sep26)─┘ -rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6 ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6 ──(Mon,Sep26)─┘ -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6 ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:37:25 on master)──> ls -ld /lib ──(Mon,Sep26)─┘ drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:38:14 on master)──> So looks like my system is not in sane state. Do I need to just delete /usr/lib/ libc and try this?. Cheers, Vasudev
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
> > I have looked at the coredump you sent me: > > $ eu-unstrip -n --core > core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300 > 0x5604c0781000+0x1e000 > b919757cbc30fbb64b14498222499d972fd80acd@0x5604c0781368 . - /usr/bin/expr > 0x7fbfabc0+0x201000 > ef3afb43092687d7fcc8167fabdee73f4a3287f1@0x7fbfabc00380 - - > /usr/lib/x86_64-linux-gnu/libc.so.6 > 0x7ffdc5bde000+0x1000 c35c947b072ff69b395cd326b83b24630f2c5065@0x7ffdc5bde54c > . - linux-vdso.so.1 > 0x7fbfac04c000+0x362b8 > a03c3b14d371da908a3f22007b3f0c73d1f9f634@0x7fbfac04c248 > /lib64/ld-linux-x86-64.so.2 - ld-linux-x86-64.so.2 > 0x7fbfabfc9000+0x80bc8 > 25c73b398493c695a013a6d9d493a8316aac0fa0@0x7fbfabfc9248 > /usr/lib/x86_64-linux-gnu/libgmp.so.10 - libgmp.so.10 > > ef3afb43092687d7fcc8167fabdee73f4a3287f1 > => comes from libc6 version 2.34-8 > a03c3b14d371da908a3f22007b3f0c73d1f9f634 > => comes from libc6 version 2.35-1 > > So the crash is likely due to a mismatch between glibc. I believe this > is due to an issue with usrmerge as the paths reported by your core file > seems to show that your system is merged, while reportbug says > "merged-usr: no". > > By using a non usrmerged system, with libc6 2.34-8 duplicated in both > /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu, and upgrading it > to libc6 2.35-1, I am able to reproduce your issue with expr: > > $ expr > *** stack smashing detected ***: terminated > Aborted Interesting. I had put init-system-helpers on hold because it was reported with some issue and I see usrmerge package is not installed on my system. usrmerge: Installed: (none) Candidate: 31 Version table: 31 500 500 http://deb.debian.org/debian sid/main amd64 Packages 500 http://deb.debian.org/debian sid/main i386 Packages 30+nmu1 -1 100 /var/lib/dpkg/status >> > And if I understand you right the stack smashing >> > is from "autoreconf --version". >> > But I could not find it executing any "expr" processes in my test VM. >> >> Actually just invoking autoconf was crashing and just executing expr itself >> was also crashing. If needed I can install latest libc and provide any >> required information. Do let me know > > Before trying to upgrade again, we should ensure your system is in a > sane state. Could you please send us the output of: > > ls -ld /lib > ls -l /lib/x86_64-linux-gnu/libc.so.6 > ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 └─(09:09:40 on master)──> ls -ld /lib ──(Mon,Sep26)─┘ drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6 ──(Mon,Sep26)─┘ -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6 ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐ └─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 ──(Mon,Sep26)─┘ -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6 ┌─(~/.emacs.d)─ Is it that if I install usrmerge and then upgrade libc it should work? Thanks and Regards, Vasudev
Processed: Re: Bug#1020705: glibc: Keep DT_HASH
Processing control commands: > reassign 1020705 src:gcc-12 Bug #1020705 [src:glibc] glibc: Keep DT_HASH Bug reassigned from package 'src:glibc' to 'src:gcc-12'. No longer marked as found in versions glibc/2.36-1. Ignoring request to alter fixed versions of bug #1020705 to the same values previously set > forcemerge 1019535 1020705 Bug #1019535 [src:gcc-12] gcc-12: please change the default hash style to both Bug #1020705 [src:gcc-12] glibc: Keep DT_HASH Severity set to 'important' from 'normal' Added indication that 1020705 affects src:glibc Marked as found in versions gcc-12/12-20220319-1. Bug #1019535 [src:gcc-12] gcc-12: please change the default hash style to both Added tag(s) patch. Merged 1019535 1020705 -- 1019535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019535 1020705: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020705 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1020705: glibc: Keep DT_HASH
control: reassign 1020705 src:gcc-12 control: forcemerge 1019535 1020705 Hi, On 2022-09-25 13:21, Jeremy Bicha wrote: > Source: glibc > Version: 2.36-1 > Tags: patch > > Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's > an article with more details: > > https://lwn.net/Articles/904892/ I already filled #1019535 which I consider is the way to go, but I am opened for discussion. I am still waiting for an answer from the GCC maintainer. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020654: C.UTF-8: surprising differences in character classes
Hi Aurelien, >Starting with glibc 2.35, we do not patch the glibc to add C.UTF-8 >support, instead we use the upstream code which comes with the following >NEWS entry [1]: […] Thanks for the extra info. >> They are as mandated by POSIX for the C locale. I believe I said >> in my original 2013 proposal for a C.UTF-8 locale that it should >> be as close to C as possible while using UTF-8 as encoding. > >Those are mandated for the POSIX C locale, but POSIX does not say >anything (yet) about the C.UTF-8 locale. Right. But, as I wrote above, my intent was to have C.UTF-8 to mirror C as closely as possible. >The choice made by upstream has been discussed during many years [2], >if you disagree with it, please come back to upstream. *sigh* but I understand your PoV. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1020705: glibc: Keep DT_HASH
Source: glibc
Version: 2.36-1
Tags: patch
Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's
an article with more details:
https://lwn.net/Articles/904892/
Below is the patch that Ubuntu 22.10 is applying. Or you could use the
Arch Linux patch
https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch
diff -pruN 2.36-1/debian/patches/restore-libc-DT_HASH.patch
2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch
--- 2.36-1/debian/patches/restore-libc-DT_HASH.patch 1970-01-01
00:00:00.0 +
+++ 2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch 2022-08-22
01:24:09.0 +
@@ -0,0 +1,32 @@
+Description: restore DT_HASH tag for libc.so.6
+ Should consider upstreaming a configure flag for this, perhaps.
+Author: Michael Hudson-Doyle
+Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29456
+Last-Update: 2022-08-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makerules
b/Makerules
+@@ -558,6 +558,9 @@
+ -Wl,--verbose 2>/dev/null | \
+ sed > $@T \
+ -e '/^=/,/^=/!d;/^=/d' \
++ -e 's/^.*\.gnu\.hash[]*:.*$$/ .note.ABI-tag :
{ *(.note.ABI-tag) } &/' \
++ -e '/^[ ]*\.hash[ ]*:.*$$/{h;d;}' \
++ -e '/DATA_SEGMENT_ALIGN/{H;g}' \
+ -e 's/^.*\*(\.dynbss).*$$/& \
+ PROVIDE(__start___libc_freeres_ptrs = .); \
+ *(__libc_freeres_ptrs) \
+--- a/Makeconfig
b/Makeconfig
+@@ -367,6 +367,10 @@
+ LDFLAGS.so += $(relro-LDFLAGS)
+ LDFLAGS-rtld += $(relro-LDFLAGS)
+
++hashstyle-LDFLAGS = -Wl,--hash-style=both
++LDFLAGS.so += $(hashstyle-LDFLAGS)
++LDFLAGS-rtld += $(hashstyle-LDFLAGS)
++
+ # Linker options to enable and disable DT_RELR.
+ ifeq ($(have-dt-relr),yes)
+ dt-relr-ldflag = -Wl,-z,pack-relative-relocs
Thank you,
Jeremy Bicha
Processed: Re: Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Processing control commands: > notfound -1 glibc/2.34-8 Bug #1020559 [libc6] libc6: After upgrading libc6 expr is crashing with "stack smashing detected" No longer marked as found in versions glibc/2.34-8. > found -1 glibc/2.35-1 Bug #1020559 [libc6] libc6: After upgrading libc6 expr is crashing with "stack smashing detected" Marked as found in versions glibc/2.35-1. -- 1020559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
control: notfound -1 glibc/2.34-8 control: found -1 glibc/2.35-1 Hello Vasudev, On 2022-09-24 21:18, Vasudev Kamath wrote: > > > Hello Vasudev, > > ok, reverting back would explain reportbug using version 2.34-8. > > > > But was this core taken at a time where all libc packages > > should have been at 2.35-1 ? > > Then I don't understand that "Module" line, > > which shows the build-id from 2.34-8. This mail should fix the BTS version. > Ah sorry I did coredumpctl debug post reverting the libc6. But core file > attached is taken when actual 2.35 was installed. I have looked at the coredump you sent me: $ eu-unstrip -n --core core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300 0x5604c0781000+0x1e000 b919757cbc30fbb64b14498222499d972fd80acd@0x5604c0781368 . - /usr/bin/expr 0x7fbfabc0+0x201000 ef3afb43092687d7fcc8167fabdee73f4a3287f1@0x7fbfabc00380 - - /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffdc5bde000+0x1000 c35c947b072ff69b395cd326b83b24630f2c5065@0x7ffdc5bde54c . - linux-vdso.so.1 0x7fbfac04c000+0x362b8 a03c3b14d371da908a3f22007b3f0c73d1f9f634@0x7fbfac04c248 /lib64/ld-linux-x86-64.so.2 - ld-linux-x86-64.so.2 0x7fbfabfc9000+0x80bc8 25c73b398493c695a013a6d9d493a8316aac0fa0@0x7fbfabfc9248 /usr/lib/x86_64-linux-gnu/libgmp.so.10 - libgmp.so.10 ef3afb43092687d7fcc8167fabdee73f4a3287f1 => comes from libc6 version 2.34-8 a03c3b14d371da908a3f22007b3f0c73d1f9f634 => comes from libc6 version 2.35-1 So the crash is likely due to a mismatch between glibc. I believe this is due to an issue with usrmerge as the paths reported by your core file seems to show that your system is merged, while reportbug says "merged-usr: no". By using a non usrmerged system, with libc6 2.34-8 duplicated in both /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu, and upgrading it to libc6 2.35-1, I am able to reproduce your issue with expr: $ expr *** stack smashing detected ***: terminated Aborted > > And if I understand you right the stack smashing > > is from "autoreconf --version". > > But I could not find it executing any "expr" processes in my test VM. > > Actually just invoking autoconf was crashing and just executing expr itself > was also crashing. If needed I can install latest libc and provide any > required information. Do let me know Before trying to upgrade again, we should ensure your system is in a sane state. Could you please send us the output of: ls -ld /lib ls -l /lib/x86_64-linux-gnu/libc.so.6 ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
On 2022-09-25 12:02, debian-bug-rep...@p0358.net wrote: > > Now that we understood the bug, I actually find strange that the > > microcode update is fixing this, it looks like that the BMI2 > > instructions support has been added in a microcode update. Would it be > > possible to give the output of /proc/cpuinfo with and without the > > microcode update applied? > > The /proc/cpuinfo without microcode update is already attached somewhere > above in the bug report, the new one after update is as follows: > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 60 > model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz > stepping: 3 > microcode : 0x28 > cpu MHz : 2400.000 > cache size : 3072 KB > physical id : 0 > siblings: 4 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 > ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt > tsc_deadline_timer xsave avx f16c rdrand lahf_lm abm cpuid_fault epb > invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept > vpid ept_ad fsgsbase tsc_adjust bmi1 smep bmi2 erms invpcid xsaveopt dtherm > arat pln pts md_clear flush_l1d > vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb > flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple > bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf > mds swapgs itlb_multihit srbds > bogomips: 4788.76 > clflush size: 64 > cache_alignment : 64 > address sizes : 39 bits physical, 48 bits virtual > power management: > > Please note that "avx2" is once again missing due to the kernel masking flag > from before that I once again forgot to remove before rebooting, and sorry > for confusion it might cause -- that flag would normally be there. > > Running a quick diff against old procinfo reveals that "flags" has the > following new entries now: > > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d > > > it looks like that the BMI2 > > instructions support has been added in a microcode update > > As such it does appear that indeed this is the case. Thanks for the confirmation, it seems that the microcode update is also useful for security reasons in order to mitigate the speculative execution side channel issues (the famous spectre/meltdown). Neverthless the AVX2 code should not use BMI2 instructions if they are not available. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Now that we understood the bug, I actually find strange that the microcode update is fixing this, it looks like that the BMI2 instructions support has been added in a microcode update. Would it be possible to give the output of /proc/cpuinfo with and without the microcode update applied? The /proc/cpuinfo without microcode update is already attached somewhere above in the bug report, the new one after update is as follows: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i3-4000M CPU @ 2.40GHz stepping: 3 microcode : 0x28 cpu MHz : 2400.000 cache size : 3072 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 smep bmi2 erms invpcid xsaveopt dtherm arat pln pts md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds bogomips: 4788.76 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: Please note that "avx2" is once again missing due to the kernel masking flag from before that I once again forgot to remove before rebooting, and sorry for confusion it might cause -- that flag would normally be there. Running a quick diff against old procinfo reveals that "flags" has the following new entries now: tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d > it looks like that the BMI2 > instructions support has been added in a microcode update As such it does appear that indeed this is the case.
Processed: bug 1019855 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=29611
Processing commands for cont...@bugs.debian.org: > forwarded 1019855 https://sourceware.org/bugzilla/show_bug.cgi?id=29611 Bug #1019855 [libc6] Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=29611'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1019855: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019855 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 1019855 in 2.34-1
Processing commands for cont...@bugs.debian.org: > found 1019855 2.34-1 Bug #1019855 [libc6] Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system Marked as found in versions glibc/2.34-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1019855: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019855 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
On 2022-09-25 00:35, debian-bug-rep...@p0358.net wrote: > Hello, sorry for delayed response, I've managed to collect and analyze a few > coredump files with valid symbols (I installed libc6-dbg and dpkg-dev, and > pointed gdb at Debian's debuginfod server, also used apt-get source to get > the sources for libc6). Thanks a lot for your work. With more data, it's way easier to understand the issue. > It seems there are at least 3-4 distinct places it crashes at, two places at > memchr-avx2.S, one at strlen-avx2.S, and potentially one at > syscall-template.S, although that last one may be just some kind of kill > signal redirect. The failing places in memchr-avx2.S and strlen-avx2.S points to BMI2 (bit manipulation instructions) which have been introduced in the AVX2 code, which should not have happened. The syscall-template.S is likely code that catches the signal to display a message and then re-emit it. > It does seem in case of this SIGILL there's no additional stack trace, also > the path containing ".." seems to cause the source code resolution to fail, > but still the debug symbols seem to show the file source and line, so it > should hopefully help see what exactly fails. > > I'm yet to try rebooting with microcode package installed though (I'll soon > check it and update on whether it helps, but even if it does, one without > bootable system first won't get a chance to install it; I'm a bit curious > how these changes did trigger this, given all these years it didn't happen > to occur before) I agree with you that this should be fixed without a microcode update, I am going to report that issue upstream and we'll get the fix in the Debian package. Now that we understood the bug, I actually find strange that the microcode update is fixing this, it looks like that the BMI2 instructions support has been added in a microcode update. Would it be possible to give the output of /proc/cpuinfo with and without the microcode update applied? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1020654: C.UTF-8: surprising differences in character classes
Hi, On 2022-09-24 23:16, Thorsten Glaser wrote: > Package: locales > Version: 2.35-1 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > While adjusting my localedata patch script to the latest glibc uploads > I discovered a surprising difference in some categories — for example: Starting with glibc 2.35, we do not patch the glibc to add C.UTF-8 support, instead we use the upstream code which comes with the following NEWS entry [1]: * Support for the C.UTF-8 locale has been added to glibc. The locale supports full code-point sorting for all valid Unicode code points. A limitation in the framework for fnmatch, regexec, and regcomp requires a compromise to save space and only ASCII-based range expressions are supported for now (see bug 28255). The full size of the locale is only ~400KiB, with 346KiB coming from LC_CTYPE information for Unicode. This locale harmonizes downstream C.UTF-8 already shipping in various downstream distributions. The locale is not built into glibc, and must be installed. The point of having it merged upstream, is that all distributions will now use the same definition for the C.UTF-8 locale, which was not the case before. > (sid-amd64)tglase@tglase:~ $ LC_ALL=C ./tstspc > U+0009 > U+000A > U+000B > U+000C > U+000D > U+0020 > (sid-amd64)tglase@tglase:~ $ LC_ALL=C.UTF-8 ./tstspc > U+0009 > U+000A > U+000B > U+000C > U+000D > U+0020 > U+1680 > U+2000 > U+2001 > U+2002 > U+2003 > U+2004 > U+2005 > U+2006 > U+2008 > U+2009 > U+200A > U+2028 > U+2029 > U+205F > U+3000 This is expected given the LC_CTYPE information used for the C.UTF-8 comes from Unicode. > The test program is thus: gcc -O2 -Wall -Wextra -Wformat -o tstspc tstspc.c > > //cut-here-- [snip] > //cut-here-- > > > In my localedata patch script, I take specific care to change the > copy of i18n_ctype before applying it to C.UTF-8 as follows: > > space → ..; > cntrl → ..; > blank → ; > > They are as mandated by POSIX for the C locale. I believe I said > in my original 2013 proposal for a C.UTF-8 locale that it should > be as close to C as possible while using UTF-8 as encoding. Those are mandated for the POSIX C locale, but POSIX does not say anything (yet) about the C.UTF-8 locale. The choice made by upstream has been discussed during many years [2], if you disagree with it, please come back to upstream. Regards Aurelien [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=faa7ec1871da1a34ed943fd8d406496e58fb2c2e;hb=f94f6d8a3572840d3ba42ab9ace3ea522c99c0c2 [2] https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
