Possible miscompilation of alacritty with -C target-cpu=native

[vorner]

Hello

I admit it is a bit hard to say where exactly the problem lies, but I think something in rustc might be to blame here. I first reported it to alacritty directly, but the more info I gather I think it might be here: alacritty/alacritty#1122.

In short, on one of my computers, alacritty crashes with this panic on start:

thread 'main' panicked at 'capacity overflow', libcore/option.rs:917:5
stack backtrace:
   0:     0x55912e09fd73 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h5be622d6bae271e4
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x55912e09e76d - std::panicking::default_hook::{{closure}}::h3dad42fd5277700a
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
                               at libstd/panicking.rs:380
   2:     0x55912e09d176 - std::panicking::rust_panic_with_hook::h17668d919cb963a0
                               at libstd/panicking.rs:396
                               at libstd/panicking.rs:576
   3:     0x55912e09cc02 - std::panicking::begin_panic::hc486239aa11674a1
                               at libstd/panicking.rs:537
   4:     0x55912e09cb79 - std::panicking::begin_panic_fmt::h2d2bb54c3df78ea1
                               at libstd/panicking.rs:521
   5:     0x55912e0b998a - core::panicking::panic_fmt::hee07a740495be6a3
                               at libstd/panicking.rs:497
   6:     0x55912e0c02a8 - core::option::expect_failed::h8c28a7270985f5ac
                               at libcore/option.rs:917
   7:     0x55912dec0e24 - <std::collections::hash::table::RawTable<K, V>>::new::h9be5b206095a0292
                               at /checkout/src/libcore/option.rs:302
                               at /checkout/src/libstd/collections/hash/table.rs:776
                               at /checkout/src/libstd/collections/hash/table.rs:816
   8:     0x55912deb825a - <std::collections::hash::map::HashMap<K, V, S>>::resize::hfcf2613f008e9ae5
                               at /checkout/src/libstd/collections/hash/map.rs:777
   9:     0x55912deb7fec - <std::collections::hash::map::HashMap<K, V, S>>::entry::h5422f5e504c51b41
                               at /checkout/src/libcore/cmp.rs:0
  10:     0x55912dea653b - alacritty::renderer::QuadRenderer::with_loader::hf63d8fc8d3d62172
                               at src/renderer/mod.rs:282
                               at src/renderer/mod.rs:214
                               at src/renderer/mod.rs:200
                               at src/display.rs:227
                               at src/renderer/mod.rs:686
  11:     0x55912ded5f4b - alacritty::display::Display::new::h18ace9deaccdd433
                               at src/display.rs:226
                               at src/display.rs:153
  12:     0x55912de09755 - alacritty::main::h023b5d1d018376be
                               at src/main.rs:104
                               at src/main.rs:62
  13:     0x55912e0f49f5 - std::rt::lang_start::{{closure}}::h924495c33c565557
                               at /checkout/src/libstd/rt.rs:74
  14:     0x55912de14f82 - main
  15:     0x7f30e925e010 - __libc_start_main
  16:     0x55912ddfaa39 - _start
  17:                0x0 - <unknown>

Further information:

• Works fine with stable.
• The last working nightly is nightly-2018-02-10, as provided by rustup.
• It is broken only on one of my computers and only when I compile it with -C target-cpu=native.

If I had to guess, I'd say it has something to do with switch to llvm 6.

Current nightly version info (still broken):

$ rustc --version --verbose
rustc 1.25.0-nightly (27a046e93 2018-02-18)
binary: rustc
commit-hash: 27a046e9338fb0455c33b13e8fe28da78212dedc
commit-date: 2018-02-18
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0

I believe my /proc/cpuinfo is also relevant (it's some low-power celeron).

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 55
model name	: Intel(R) Celeron(R) CPU  N2940  @ 1.83GHz
stepping	: 8
microcode	: 0x829
cpu MHz		: 499.609
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
bugs		: cpu_meltdown spectre_v1 spectre_v2
bogomips	: 3666.91
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Is there any other way I could narrow it down further, or anything more I could try?

[matthiaskrgr]

For the record, if you run rustc -C target-cpu=help it will tell you exactly as what your cpu is recognized (2nd line) :)

[vorner]

Hmm. It says amdfam10, which seems wrong, considering this CPU is intel (and I could see why that would produce strange crashes).

How does it detect the CPU? Does it rely on some library present in the OS, or is everything bundled within the tarball downloaded by rustc? (I ask because I have an unusual setup ‒ this is gentoo and the packages for the computer are compiled on a different computer, so some library in the OS could in theory provide the info from the time it was compiled, not where it runs, but it sounds unlikely).

[vorner]

Just to add, the 2018-02-10 version guesses silvermont.

[matthiaskrgr]

Just curious, if you run dmesg --follow, do you see something like "illegal instruction" or "invalid opcode" at the bottom when you execute the probably miscompiled binary?

[sanxiyn]

Host CPU detection is done by LLVM here.

[nagisa]

@vorner are you sure you looked at the

native - Select the CPU of the current host (currently something).

and not

amdfam10 - Select the amdfam10 processor.

amdfam10 is definitely not something that should be detected for intel.

[vorner]

@nagisa Yes, I'm sure (and just double-checked).

    native         - Select the CPU of the current host (currently amdfam10).

The fact the amdfam10 is first in the list is suspicious, though (something initialized to 0 and not set later on, maybe). I fully agree this should not be detected on intel.

(As for the dmesg and illegal instruction, I'll report back in ~30 minutes ‒ I have to get back to the broken state and the processor is slow).

[vorner]

@matthiaskrgr No illegal instruction dmesg, only well-behaved panic. But I think it is possible there exists an instruction opcode that means one thing on the amdfam10 processor and something completely different on the intel one.

[vitalyd]

I'd have expected a SIGILL if a truly illegal/unsupported instruction was attempted, rather than an assertion panic inside Rust code. The tricky bit here is that amdfam10 supports the x86-64 ISA, and even some SSE extensions; as does silvermont, of course.

Perhaps the panic can be turned into an abort, get a core dump, and then look at the disassembly of the frames in the backtrace. In particular, what capacity is the HashMap trying to resize to? That seems to cause an overflow in multiplication, and perhaps it's getting some bogus value. Then maybe it's possible to trace back to see where this value is produced, and perhaps there's some sort of miscompile there.

Or, can skip that and try to figure out why cpu detection is off in the first place. @vorner, you said that this nightly version works fine if you manually select silvermont?

[vorner]

It works fine if I pass no RUSTFLAGS (eg. compile generic code). I'm compiling with explicit silvermont now, but I'd expect that to work too.

[vitalyd]

@vorner, does it always fail with target-cpu=native? And always in the same place?

[vorner]

If I explicitly select silvermont, it also works correctly.

With native, it always fails and the function names and line numbers in the backtrace are the same. The addresses on the left differ, probably due to some kind of address space randomization.

[vorner]

I believe it is the choice of wrong processor during the compilation. But I still went with the panic = "abort" experiment and created a core file. The capacity is something ridiculously large.

#0  0x00007fc8f9e14f70 in raise () from /lib64/libc.so.6
#1  0x00007fc8f9e16b3d in abort () from /lib64/libc.so.6
#2  0x000055d97fc994b9 in panic_abort::__rust_start_panic::abort () at libpanic_abort/lib.rs:62
#3  0x000055d97fc994a9 in __rust_start_panic () at libpanic_abort/lib.rs:57
#4  0x000055d97fc82cba in rust_panic () at libstd/panicking.rs:431
#5  std::panicking::rust_panic_with_hook () at libstd/panicking.rs:416
#6  0x000055d97fc8254e in std::panicking::begin_panic_fmt () at libstd/panicking.rs:347
#7  0x000055d97fc9b40b in rust_begin_unwind () at libstd/panicking.rs:323
#8  core::panicking::panic_fmt () at libcore/panicking.rs:71
#9  0x000055d97fca1e59 in core::option::expect_failed () at libcore/option.rs:917
#10 0x000055d97fb182f4 in <std::collections::hash::table::RawTable<K, V>>::new (capacity=576460752303423488) at /checkout/src/libcore/option.rs:302
#11 0x000055d97fb0991d in <std::collections::hash::map::HashMap<K, V, S>>::resize (self=0x7ffcd0d78c20, new_raw_cap=140723812268032)
    at /checkout/src/libstd/collections/hash/map.rs:802
#12 0x000055d97fb0969d in <std::collections::hash::map::HashMap<K, V, S>>::entry (self=0x7ffcd0d78c20, key=...) at /checkout/src/libcore/cmp.rs:462
#13 0x000055d97fb30460 in alacritty::display::Display::new (config=0x7ffcd0d79f10, options=0x7ffcd0d7a5e8) at src/renderer/mod.rs:282
#14 0x000055d97faad14a in alacritty::main () at src/main.rs:104

I'm attaching the core file and corresponding binary, if you want to look into it.

core.zip