[Bug 1162283] New: rust emits SSE2 for i586 (SIGILL)
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Bug ID: 1162283 Summary: rust emits SSE2 for i586 (SIGILL) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i586 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: luke@ljones.dev Reporter: jengelh@inai.de QA Contact: qa-bugs@suse.de CC: aplanas@suse.com, dimstar@opensuse.org Found By: --- Blocker: --- AFAICS, not the same as bug #1077870 but similar in spirit. A large part of an X desktop is unusable due to a crash caused by rust emitting SSE2 for the i586 target, causing a SIGILL crash in librsvg... so basically whenever something wants to display an SVG icon, which happens all the time I would argue. # gdb /usr/bin/xfce4-settings-manager Reading symbols from /usr/bin/xfce4-settings-manager... Reading symbols from /usr/lib/debug/usr/bin/xfce4-settings-manager-4.14.2-1.1.i386.debug... (gdb) r Starting program: /usr/bin/xfce4-settings-manager Missing separate debuginfos, use: zypper install glibc-debuginfo-2.30-2.2.i686 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xb6020b40 (LWP 6458)] [New Thread 0xb56ffb40 (LWP 6459)] [New Thread 0xb4868b40 (LWP 6460)] Thread 1 "xfce4-settings-" received signal SIGILL, Illegal instruction. 0xb3ea2a53 in <&str as std::ffi::c_str::CString::new::SpecIntoVec>::into_vec () from /usr/lib/librsvg-2.so.2 (gdb) bt #0 0xb3ea2a53 in <&str as std::ffi::c_str::CString::new::SpecIntoVec>::into_vec () from /usr/lib/librsvg-2.so.2 #1 0xb3dce649 in std::ffi::c_str::CString::new (t=...) at /home/abuild/rpmbuild/BUILD/rustc-1.40.0-src/src/libstd/ffi/c_str.rs:354 #2 glib::subclass::types::register_type () at /usr/src/debug/librsvg-2.46.4-0.i386/vendor/glib/src/subclass/types.rs:474 #3 0xb3ea9947 in std::sync::once::Once::call_inner () from /usr/lib/librsvg-2.so.2 #4 0xb3cff82b in rsvg_rust_handle_get_type () at /home/abuild/rpmbuild/BUILD/rustc-1.40.0-src/src/libstd/sync/once.rs:224 #5 0xb3cfceb4 in rsvg_handle_get_type () at librsvg/rsvg-handle.c:422 #6 0xb3cfdd25 in rsvg_handle_new () at librsvg/rsvg-handle.c:467 (gdb) disas Dump of assembler code for function _ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E: 0xb3ea29b0 <+0>: push %ebp 0xb3ea29b1 <+1>: push %ebx 0xb3ea29b2 <+2>: push %edi 0xb3ea29b3 <+3>: push %esi 0xb3ea29b4 <+4>: sub $0x2c,%esp 0xb3ea29b7 <+7>: mov 0x40(%esp),%edi 0xb3ea29bb <+11>: call 0xb3ea29c0 <_ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E+16> 0xb3ea29c0 <+16>: pop %ebx 0xb3ea29c1 <+17>: add $0x1c0640,%ebx 0xb3ea29c7 <+23>: mov %edi,%ebp 0xb3ea29c9 <+25>: inc %ebp 0xb3ea29ca <+26>: js 0xb3ea2a6c <_ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E+188> 0xb3ea29d0 <+32>: mov %ecx,%esi 0xb3ea29d2 <+34>: test %ebp,%ebp 0xb3ea29d4 <+36>: mov %edx,0x1c(%esp) 0xb3ea29d8 <+40>: je 0xb3ea29f4 <_ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E+68> 0xb3ea29da <+42>: mov %ebp,(%esp) 0xb3ea29dd <+45>: call 0xb3cfbd60 <malloc@plt> 0xb3ea29e2 <+50>: test %eax,%eax 0xb3ea29e4 <+52>: jne 0xb3ea29f9 <_ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E+73> 0xb3ea29e6 <+54>: mov %ebp,%ecx 0xb3ea29e8 <+56>: mov $0x1,%edx 0xb3ea29ed <+61>: call 0xb3d0ccb0 <_ZN5alloc5alloc18handle_alloc_error17haf41c57d90e6bc24E> 0xb3ea29f2 <+66>: ud2 0xb3ea29f4 <+68>: mov $0x1,%eax 0xb3ea29f9 <+73>: lea 0x20(%esp),%ecx 0xb3ea29fd <+77>: lea 0x10(%esp),%edx 0xb3ea2a01 <+81>: mov %eax,0x10(%esp) 0xb3ea2a05 <+85>: mov %ebp,0x14(%esp) 0xb3ea2a09 <+89>: movl $0x0,0x18(%esp) 0xb3ea2a11 <+97>: mov %edi,0x4(%esp) 0xb3ea2a15 <+101>: movl $0x1,0x8(%esp) 0xb3ea2a1d <+109>: movl $0x0,(%esp) 0xb3ea2a24 <+116>: call 0xb3ea4b20 <_ZN5alloc7raw_vec19RawVec$LT$T$C$A$GT$16reserve_internal17h6e3cd1f8aa0966f3E> 0xb3ea2a29 <+121>: cmpl $0x1,0x20(%esp) 0xb3ea2a2e <+126>: je 0xb3ea2a73 <_ZN70_$LT$$RF$str$u20$as$u20$std..ffi..c_str..CString..new..SpecIntoVec$GT$8into_vec17h099ffe789070d331E+195> 0xb3ea2a30 <+128>: mov 0x18(%esp),%eax 0xb3ea2a34 <+132>: mov %edi,0x8(%esp) 0xb3ea2a38 <+136>: lea (%eax,%edi,1),%ecx 0xb3ea2a3b <+139>: mov %ecx,0x18(%esp) 0xb3ea2a3f <+143>: mov 0x1c(%esp),%ecx 0xb3ea2a43 <+147>: add 0x10(%esp),%eax 0xb3ea2a47 <+151>: mov %ecx,0x4(%esp) 0xb3ea2a4b <+155>: mov %eax,(%esp) 0xb3ea2a4e <+158>: call 0xb3cfba20 <memcpy@plt> => 0xb3ea2a53 <+163>: movsd 0x10(%esp),%xmm0 0xb3ea2a59 <+169>: mov 0x18(%esp),%eax 0xb3ea2a5d <+173>: movsd %xmm0,(%esi) 0xb3ea2a61 <+177>: mov %eax,0x8(%esi) 0xb3ea2a64 <+180>: add $0x2c,%esp 0xb3ea2a67 <+183>: pop %esi 0xb3ea2a68 <+184>: pop %edi 0xb3ea2a69 <+185>: pop %ebx 0xb3ea2a6a <+186>: pop %ebp 0xb3ea2a6b <+187>: ret 0xb3ea2a6c <+188>: Dwarf Error: Cannot find DIE at 0x3f7e13 referenced from DIE at 0x3f8ba9 [in module /usr/lib/debug/usr/lib/librsvg-2.so.2.46.0-2.46.4-0.i386.debug] # lscpu Architecture: i686 CPU op-mode(s): 32-bit Byte Order: Little Endian Address sizes: 34 bits physical, 32 bits virtual CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Vendor ID: AuthenticAMD CPU family: 6 Model: 8 Model name: AMD Athlon(tm) XP 2000+ Stepping: 0 CPU MHz: 1666.773 BogoMIPS: 3333.54 L1d cache: 64 KiB L1i cache: 64 KiB L2 cache: 256 KiB Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mm xext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall Packages used: librsvg-2-2-2.46.4-0.i586.rpm that built with rust-1.40. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Thomas Zimmermann <tzimmermann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tzimmermann@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c1 --- Comment #1 from Luke Jones <luke@ljones.dev> --- Not entirely sure what to do about this. i586 is unsupported by Rust (tier 2) and as such the package is built for i686. However! building does use i586 packages, and so I think this is where the issue is coming from. There's really not much to be done at the root of this bar SUSE dropping i586 and moving to i686 completely. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c2 --- Comment #2 from Jan Engelhardt <jengelh@inai.de> --- Changing to i686 does not help: the i686 ISA does not mandate the presence of SSE instructions either. That was only introduced with the x86_64 ABI. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c3 --- Comment #3 from Thomas Zimmermann <tzimmermann@suse.com> --- Hi, as I've been recently affected by this problem, I'd already find it helpful to know which packages require SSE2. Would it be possible to name such packages with .i786 [1] instead of .i586? [1] https://en.wikipedia.org/wiki/I786 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c4 --- Comment #4 from Jan Engelhardt <jengelh@inai.de> --- So RPM does not have a "i786" architecture, and though one can be added with a little config, that is not helpful (i786 is not a thing, and neither is i586 actually, and it is unfortunate i586 has found its way into rpm—updated the wiki pages). But there is "pentium4", albeit it's just an alias for the base 386 plus -march=. It does not enable SSE in its own right, so there is some config to be done in either case. Not only that, you would also have to teach zypper and OBS about the special case that pentium4 is (similar to how i686 is used) and that zypper shall not install a pentium4 rpm on a non-SSE2 machine (because rpm does not care what you install). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c5 --- Comment #5 from Thomas Zimmermann <tzimmermann@suse.com> --- (In reply to Jan Engelhardt from comment #4)
So RPM does not have a "i786" architecture, and though one can be added with a little config, that is not helpful (i786 is not a thing, and neither is i586 actually, and it is unfortunate i586 has found its way into rpm—updated the wiki pages). But there is "pentium4", albeit it's just an alias for the base 386 plus -march=. It does not enable SSE in its own right, so there is some config to be done in either case.
Not only that, you would also have to teach zypper and OBS about the special case that pentium4 is (similar to how i686 is used) and that zypper shall not install a pentium4 rpm on a non-SSE2 machine (because rpm does not care what you install).
I'm just looking for a simple way to see if a package uses SSE2. If so, I can try to find an alternative program or avoid installing the package in the first place. I don't care if zypper installs these packages automatically. I'm not proposing to change any dependencies. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Kevin Brace <kevinbrace@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevinbrace@gmx.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c6 --- Comment #6 from Kevin Brace <kevinbrace@gmx.com> --- I also observed similar invalid opcode trap crashes when I installed openSUSE Tumbleweed i586 on VIA Embedded EPIA-M mainboard. This board has a VIA Technologies C3 processor, hence, no support for SSE2 instruction set. I picked openSUSE Tumbleweed i586 since it is probably the only major Linux distribution that does not require PAE (Page Address Extension) support. The invalid opcode trap crashes happened with librsvg-2. As of now, I am not able to run LXDE properly probably due to this bug. Please fix this issue ASAP. I develop OpenChrome graphics stack, and I really need openSUSE Tumbleweed i586 to work properly in order to test the code with C3 processor / CLE266 chipset combination. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Luke Jones <luke@ljones.dev> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|luke@ljones.dev |screening-team-bugs@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Thomas Zimmermann <tzimmermann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugzilla.opensuse.or | |g/show_bug.cgi?id=1190409 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c9 --- Comment #9 from Stefan Dirsch <sndirsch@suse.com> --- We saw similar issue with Mesa (boo#1190409, "-msse2" option) . Do we really need/want to support such old machines from 2001 and older? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9868 What does this mean for users? On Linux raises the default minimum processor spec to SSE2 supporting CPUs Intel requirements raise from P5 (1993) to Netburst (2000) AMD requirements raise from Athlon(1999/2000) to Athlon 64 (2003) Via requirements raise from C3(2001) to C7 (2005) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 http://bugzilla.opensuse.org/show_bug.cgi?id=1162283#c10 --- Comment #10 from Jan Engelhardt <jengelh@inai.de> --- Today it's -msse2, tomorrow it's -mavx512. I would not mind if upstream - concerning any package - explicitly communicates "no more support for <platform>", and, at best, encodes that into program logic with cpuid() and abort() calls right at the top of main(). What I do mind is that boldness to add -m flags rather discretely (no one seriously reads compiler logs unless it fails) and cause spurious crashes on 20% of our users because some poor soul dared to execute it on a CPU that does not match the upstream developer's silicon. It's just a shitty user experience. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1162283 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com