Description of problem: Execution of the swift (REPL) and swiftc (Compiler) is halted and crashed for an "illegal hardware instruction" Version-Release number of selected component (if applicable): swift-lang-5.3-1 How reproducible: Always Steps to Reproduce: 1. Install via dnf (sudo dnf install swift-lang) 2. execute: swift or swiftc Actual results: swift (REPL) execution: Stack dump: 0. Program arguments: swift 1. Swift version 5.3 (swift-5.3-RELEASE) #0 0x0000000004cea8cf llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/libexec/swift/bin/swift+0x4cea8cf) #1 0x0000000004ce8bc0 llvm::sys::RunSignalHandlers() (/usr/libexec/swift/bin/swift+0x4ce8bc0) #2 0x0000000004ceacf5 SignalHandler(int) (/usr/libexec/swift/bin/swift+0x4ceacf5) #3 0x00007f8c696a71e0 __restore_rt (/lib64/libpthread.so.0+0x141e0) #4 0x00000000018a43b2 std::vector<swift::DiagnosticState::Behavior, std::allocator<swift::DiagnosticState::Behavior> >::_M_fill_insert(__gnu_cxx::__normal_iterator<swift::DiagnosticState::Behavior*, std::vector<swift::DiagnosticState::Behavior, std::allocator<swift::DiagnosticState::Behavior> > >, unsigned long, swift::DiagnosticState::Behavior const&) (/usr/libexec/swift/bin/swift+0x18a43b2) #5 0x000000000189d602 swift::DiagnosticState::DiagnosticState() (/usr/libexec/swift/bin/swift+0x189d602) #6 0x00000000004ebccc run_driver(llvm::StringRef, llvm::ArrayRef<char const*>) (/usr/libexec/swift/bin/swift+0x4ebccc) #7 0x00000000004eb098 main (/usr/libexec/swift/bin/swift+0x4eb098) #8 0x00007f8c691031a2 __libc_start_main (/lib64/libc.so.6+0x281a2) #9 0x00000000004eac2e _start (/usr/libexec/swift/bin/swift+0x4eac2e) [1] 145877 illegal hardware instruction (core dumped) swift swiftc (Compiler) execution: Stack dump: 0. Program arguments: swiftc 1. Swift version 5.3 (swift-5.3-RELEASE) #0 0x0000000004cea8cf llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/libexec/swift/bin/swift+0x4cea8cf) #1 0x0000000004ce8bc0 llvm::sys::RunSignalHandlers() (/usr/libexec/swift/bin/swift+0x4ce8bc0) #2 0x0000000004ceacf5 SignalHandler(int) (/usr/libexec/swift/bin/swift+0x4ceacf5) #3 0x00007f92371191e0 __restore_rt (/lib64/libpthread.so.0+0x141e0) #4 0x00000000018a43b2 std::vector<swift::DiagnosticState::Behavior, std::allocator<swift::DiagnosticState::Behavior> >::_M_fill_insert(__gnu_cxx::__normal_iterator<swift::DiagnosticState::Behavior*, std::vector<swift::DiagnosticState::Behavior, std::allocator<swift::DiagnosticState::Behavior> > >, unsigned long, swift::DiagnosticState::Behavior const&) (/usr/libexec/swift/bin/swift+0x18a43b2) #5 0x000000000189d602 swift::DiagnosticState::DiagnosticState() (/usr/libexec/swift/bin/swift+0x189d602) #6 0x00000000004ebccc run_driver(llvm::StringRef, llvm::ArrayRef<char const*>) (/usr/libexec/swift/bin/swift+0x4ebccc) #7 0x00000000004eb098 main (/usr/libexec/swift/bin/swift+0x4eb098) #8 0x00007f9236b751a2 __libc_start_main (/lib64/libc.so.6+0x281a2) #9 0x00000000004eac2e _start (/usr/libexec/swift/bin/swift+0x4eac2e) [1] 146395 illegal hardware instruction (core dumped) swiftc Expected results: swift (REPL): I expect to have access to the interactive environment swiftc (Compiler): I expect to be able to compile a program without failure by the compiler or even receive a version back if I use swiftc --version Additional info: This problem has been persistent since Fedora 32 and package version swift-lang-5.2.(3-4)
Created attachment 1721921 [details] Swift Dump Swift dump pull via cordumpctl dump swift --output swift.dump
Created attachment 1721922 [details] Swiftc Dump Swift dump pull via cordumpctl dump swiftc --output swiftc.dump
Gee, sorry about that. Is this x86_64 or aarch64?
My apologies form not selecting that on bug report. The package is the x86_64 version.
Huh, that's really weird; I use Swift daily on my F32 laptop and F33 server. Did you try removing and re-installing it?
Also can I get some info about your environment (memory, processor type, etc.) Is this an AMD-based machine by chance?
My hardware spec is: CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 945 Processor stepping : 2 microcode : 0x10000db cpu MHz : 3000.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bogomips : 6027.49 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate I ran the core through lldb to see more details. I re-ran the program; I see it crashes on a pshufb %xmm1, %xmm0 instruction. Since the program is crashing with an "illegal hardware instruction" error and pshufb is an SSE3 instruction. I assumed that I don't have SSE3-4 support. So, I check CPU specs through /proc/cpuinfo and find out that my CPU does have SSE/pni and a small subset of sse4. That stomped me that about as far as I can go. Sorry!
Two if this 16 GB total: Handle 0x0028, DMI type 17, 27 bytes Memory Device Array Handle: 0x0024 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8 GB Form Factor: DIMM Set: None Locator: A3 Bank Locator: Bank6/7 Type: Unknown Type Detail: None Speed: 1333 MT/s Manufacturer: Serial Number: Asset Tag: Part Number:
(In reply to Ron Olson from comment #5) > Huh, that's really weird; I use Swift daily on my F32 laptop and F33 server. > Did you try removing and re-installing it? Yes I did try uninstalling it while I was on F32 several times with out success. The only thing that worked was doing a force downgrade. I'd uninstall swift-lang then called swiftc (after uninstall) this force F32 to prompt me to install it. I say yes, BUT this gave me the older version 5.2.(3-4) not 5.3. Oddest thing about this is that It works on my laptop without any hiccups. An old HP Pavilion 15-n048ca - 15.6" - A8 5545M - 8 GB RAM - 750 GB HDD Now that I decide to start fresh with F33. I did a full system wipe. Installed F33 and swift-lang now I'm getting the same crash + can't downgrade.
Can you post the CPU specs of the HP? I personally don't have any AMD-based machines though I think I can get my hands on one if necessary to see if I can reproduce. I will also ask upstream if they have any suggestions.
(In reply to Ron Olson from comment #10) > Can you post the CPU specs of the HP? I personally don't have any AMD-based > machines though I think I can get my hands on one if necessary to see if I > can reproduce. I will also ask upstream if they have any suggestions. (CORRECTION) Laptop Model: HP Pavilion (15-b119wm) AMD A8 Quadcore - 6 GB Memory - 750GB HDD CPU Specs: processor : [0-3] vendor_id : AuthenticAMD cpu family : 21 model : 16 model name : AMD A8-4555M APU with Radeon(tm) HD Graphics stepping : 1 microcode : 0x6001119 cpu MHz : 1101.087 cache size : 2048 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 2 apicid : 19 initial apicid : 3 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 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass bogomips : 3194.14 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro Memory Specs: Handle 0x001C, DMI type 17, 34 bytes Memory Device Array Handle: 0x001B Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 2 GB Form Factor: SODIMM Set: None Locator: Bottom-Slot 1(top) Bank Locator: CHANNEL A Type: DDR3 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 1333 MT/s Manufacturer: Hynix Serial Number: 4FB11A22 Asset Tag: Asset Tag: Part Number: HMT325S6EFR8A-PB Rank: 1 Configured Memory Speed: 667 MT/s Handle 0x001F, DMI type 17, 34 bytes Memory Device Array Handle: 0x001B Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4 GB Form Factor: SODIMM Set: None Locator: Bottom-Slot 2(under) Bank Locator: CHANNEL B Type: DDR3 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 1333 MT/s Manufacturer: Samsung Serial Number: E15006E4 Asset Tag: Asset Tag: Part Number: M471B5273CH0-YK0 Rank: 2 Configured Memory Speed: 667 MT/s I'm beginning to think that for the next time I report bugs I should put all these SPECS on a file and uploaded. Instead of making such a mess on the posts and replies for you maintainers.
Just letting you know I'm trying to find an AMD machine to look into this; I cannot reproduce the issue on any Intel-based machine from Core 2 Duo to Xeon.
Hey, as an update, I was able to procure an AMD server and was able to reproduce the error. I have successfully built Swift to run on it via some patches to get around the use of SSSE3, but the resulting build is, ironically, AMD-only; it runs fine on the AMD server but not on Intel-based machines. I'm trying to figure out if there's a way to make it do both but as an alternative, would an AMD-specific RPM on COPR be an acceptable substitute? Ultimately it's an issue with the age of the AMD processors in question and as you point out, your AMD-based laptop with ssse3 does not have this problem.
*** Bug 1893837 has been marked as a duplicate of this bug. ***
FEDORA-2020-32cfd6fbd2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-32cfd6fbd2
FEDORA-2020-32e138e07f has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-32e138e07f
FEDORA-2020-6015cea607 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6015cea607
FEDORA-EPEL-2020-c1521cabff has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c1521cabff
FEDORA-2020-32cfd6fbd2 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-32cfd6fbd2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-32cfd6fbd2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-32e138e07f has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-32e138e07f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-32e138e07f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6015cea607 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6015cea607` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6015cea607 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-c1521cabff has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c1521cabff See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-32cfd6fbd2 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-32e138e07f has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-c1521cabff has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.