'illegal hardware instruction' when attempting to run Bear on core2 CPU

[rsvensson]

Describe the bug When trying to run bear on my old laptop with a Core2Duo CPU it fails with the error 'illegal hardware instruction'. Compilation works fine and produces a working binary when not using bear. I'm using the Arch Linux package of bear, which works perfectly fine on my desktop PC using a zen3 CPU. At first I thought it was related to me using a cross-compiler, but it happens even with a simple hello world C file using standard GCC. It could of course be caused by something other than the CPU used as it does seem strange, but 'illegal hardware instruction' sounds CPU related to me.

The following backtrace is produced when running bear --verbose -- gcc -o test test.c with a simple hello world C file:

#0  0x000055d35b4e3c73 in void fmt::v9::detail::vformat_to<char>(fmt::v9::detail::buffer<char>&, fmt::v9::basic_string_view<char>, fmt::v9::basic_format_args<fmt::v9::basic_format_context<std::conditional<std::is_same<fmt::v9::type_identity<char>::type, char>::value, fmt::v9::appender, std::back_insert_iterator<fmt::v9::detail::buffer<fmt::v9::type_identity<char>::type> > >::type, fmt::v9::type_identity<char>::type> >, fmt::v9::detail::locale_ref) ()
#1  0x000055d35b4f59f8 in void spdlog::logger::log_<char const* const&, char const (&) [6]>(spdlog::source_loc, spdlog::level::level_enum, fmt::v9::basic_string_view<char>, char const* const&, char const (&) [6]) ()
#2  0x000055d35b4f405c in ps::ApplicationLogConfig::record(char const**, char const**) const ()
#3  0x000055d35b4fa1b5 in std::_Function_handler<void (flags::Arguments const&), ps::ApplicationFromArgs::command(int, char const**, char const**) const::{lambda(auto:1 const&)#1}>::_M_invoke(std::_Any_data const&, flags::Arguments const&) ()
#4  0x000055d35b4fa570 in ps::ApplicationFromArgs::command(int, char const**, char const**) const ()
#5  0x000055d35b4cdba8 in int ps::main<bear::Application>(int, char**, char**) ()
#6  0x00007fc1a2c3c790 in ?? () from /usr/lib/libc.so.6
#7  0x00007fc1a2c3c84a in __libc_start_main () from /usr/lib/libc.so.6
#8  0x000055d35b4d0c05 in _start ()

When attempting to build bear from source, it fails the intercept and citnames unit tests with an Illegal exception as well:

[...]
    Start 6: bear::intercept_unit_test
6/7 Test #6: bear::intercept_unit_test ........***Exception: Illegal  0.24 sec
    Start 7: bear::citnames_unit_test
7/7 Test #7: bear::citnames_unit_test .........***Exception: Illegal  0.21 sec

This also happens even if I specify -march=core2 as a CFLAGS and CXXFLAGS option. There were no further details in the test log that I could see, other than that it failed at the first step.

The CPU in question is a Core2Duo T7250 with the following 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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority vpid dtherm ida

To Reproduce For me it's as simple as compiling any C file on a core2duo CPU on Arch Linux.

Expected behavior Bear should function correctly regardless of what X86_64 CPU I'm using.

Environment:

• OS name: Linux
• OS version: Arch Linux
• OS architecture: x86_64
• Bear version: 3.1.0
• Bear install method: pacman -S bear
• Other: Kernel is the standard Arch Linux x86_64 kernel.

Thanks for making this wonderful tool. Please let me know if I can supply any additional information.

[rizsotto]

Hey @rsvensson , thanks for this report. This is an interesting error.

After searching for the "illegal hardware instruction" message, I've learned that this happens when the compiled binary is using an instruction code (of the CPU) that is not available on the actual CPU. (eg.: when using an avx2 instruction, while your CPU is not capable of avx2 instructions.)

If this is true, then as a maintainer of the source code of the program, I can't do much about it. It's more likely the package creation issue... As a workaround I would recommend to compile Bear from source on your machine, with the appropriate compiler flags, to ensure that it is able to run on your machine's CPU.

[rsvensson]

Thanks for your reply. Yes indeed, this was my first assumption (although as far as I know all Arch Linux packages are compatible on all x86_64 CPUs), which is why I tried compiling it from source myself as I mentioned. But in that case the unit tests are failing with the same exception even when I specify core2 as march, which I think should be enough to prevent any unsupported instructions.

I will try to compile again with a generic march rather than core2.

[rsvensson]

So compiling it with -march=x86-64 made no difference to my issue. I do understand it's out of your control though, and it's most likely some weird issue on my end. I have absolutely no idea what it could be though, and so far this is the only time I've ran into this.