OS X, illegal hardware instruction with 0.21.0

[bmatzner]

In a nuxt application, using sharp as adapter with responsive-loader, on MacOS, v0.21.0 causes "illegal hardware instruction", while 0.20.8 was working fine. Not sure what other installation details might be helpful…

[lovell]

Hello, are you using the pre-built binaries for both sharp and libvips? What CPU(s) does this occur on? What is the output of sysctl -a | grep machdep.cpu?

The pre-built binaries are created using Travis CI's OS X environment. v0.21.0 involved an upgrade from xcode8 to xcode9.2 so it's possible the later version of clang detected a newer CPU intrinsic on the Travis machine that we might need to switch off.

[lovell]

This could also be related to #1213 - does adding sharp.simd(false) fix this?

[mceachen]

I've just hit this too (or possibly another issue with 0.21.0) in CI when running my test suite under mocha. My build box is Mac OS X 10.11.6 (El Capitan), node 8.9.4.

sharp.simd(false) did not fix it. Reverting to sharp v0.20.0 does.

$ NODE_ENV=test node_modules/.bin/mocha 'dist/**/*.spec.js'
Illegal instruction: 4

$ gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ sysctl -a | grep machdep.cpu
machdep.cpu.max_basic: 11
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
machdep.cpu.family: 6
machdep.cpu.model: 37
machdep.cpu.extmodel: 2
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 5
machdep.cpu.feature_bits: 187713022065376255
machdep.cpu.extfeature_bits: 4967106816
machdep.cpu.signature: 132693
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID
machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF RDTSCP TSCI
machdep.cpu.logical_per_package: 16
machdep.cpu.cores_per_package: 8
machdep.cpu.microcode_version: 6
machdep.cpu.processor_flag: 4
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 4384
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 1
machdep.cpu.thermal.invariant_APIC_timer: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 0
machdep.cpu.thermal.fine_grain_clock_mod: 0
machdep.cpu.thermal.package_thermal_intr: 0
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.energy_policy: 0
machdep.cpu.arch_perf.version: 3
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 4
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 8
machdep.cpu.cache.size: 256
machdep.cpu.tlb.inst.small: 64
machdep.cpu.tlb.inst.large: 7
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.data.large: 32
machdep.cpu.tlb.shared: 512
machdep.cpu.address_bits.physical: 36
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 2
machdep.cpu.thread_count: 4
machdep.cpu.tsc_ccc.numerator: 0
machdep.cpu.tsc_ccc.denominator: 0

[lovell]

Thanks @mceachen, this is very useful information.

The CPU described here is an Intel Westmere from circa 2010 that lacks AVX intrinsics.

Travis probably updated their OS X machines recently to use Sandy Bridge or later which do.

Two possible solutions:

1. Prevent the use of AVX (or later) intrinsics in the pre-built OS X binaries - would involve adding something like HOMEBREW_OPTFLAGS="-mno-avx" to https://github.com/lovell/package-libvips-darwin/blob/master/.travis.yml

2. Check CPU flags at install time and prevent use of pre-built OS X binaries for machines without AVX.

As a workaround for now you can install vips from source via homebrew, which will compile for the relevant CPU.

[mceachen]

Thanks (always) for your help, sir! That was absolutely the issue.

Given how user-hostile Apple has been lately with their hardware (like soldering both the RAM and the hard drive to the motherboard), you may find more and more people are running on antiques. How much performance are you leaving on the table by disabling AVX extensions?

For the homebrew-uninitiated (like me), the magick incantation was

brew install vips --build-from-source
rm -rf node_modules
yarn # or npm install

[mceachen]

@lovell thanks again for you help. When sharp is compiled against brew libraries, do you know if there is a magic option/param/env I can set to tell ar (or whatever) to pull libvips into the final sharp.node, so it can be redistributed?

[lovell]

@mceachen You'll probably want to adapt https://github.com/lovell/package-libvips-darwin for your purposes.

[bmatzner]

I happen to run the same setup as @mceachen

After installing vips from source via homebrew as advised here, the installation of the sharp package and build via node-gyp caused a number of warnings, the package is running smoothly, however, much faster than jimp.

Thanks @lovell and @mceachen

Leaving the issue open for now, as the approach requires special steps and is more of a workaround than a resolution. Please do, however, close as you see fit.

[lovell]

Here's an OS X tarball that has (hopefully) been compiled without AVX instructions - see commit lovell/package-libvips-darwin@f37bd2c

libvips-8.7.0-darwin-x64.tar.gz

Are you able to test? If so, please save it to your local ~/.npm/_libvips folder and re-install sharp (you'll need to remove any brew-installed vips first).

[bmatzner]

Sorry, still results in illegal hardware instruction

[lovell]

@bmatzner Thanks for checking, I'll have another think about what can be done.

[lovell]

Commit lovell/package-libvips-darwin@2c84f3a takes advantage of a side effect of the --build-bottle flag so the vips package is compiled with -march=core2.

The result of this is libvips-8.7.0-darwin-x64.tar.gz

Are you able to test again? If so, you'll need to remove node_modules/sharp and any brew-installed vips first before saving the tarball to your local ~/.npm/_libvips folder and re-installing sharp.

[mceachen]

🎉 that works for me--the code that caused node to crash now runs and passes my tests.

Thanks @lovell, you rock! Will you be pushing a new version with this change to the build configuration?

[e-tip]

Thanks @lovell your latest build of libvips fixed also for me the issue with illegal instructions

[lovell]

Thanks for confirming, this is now the "official" tarball served for v8.7.0. Anyone else experiencing this problem on OS X with non-AVX Intel CPUs should remove the ~/.npm/_libvips directory and re-install sharp.

[mceachen]

Confirmed working with the published tarball, thanks again, @lovell

[TommyGrealyIntel]

Hi, I know this issue has been closed but I am still seeing it:
-El Capitan, osx version 10.11.6 (15G22010)

I followed the steps above, removed the libvips 8.7.4 tarball and placed the 8.7.0 version into the ~/.npm/_libvips directory as described above. Then:
npm uninstall sharp
Followed by
npm install sharp

The install process seems to pull down the 8.7.4 version of libvips again and I get the error:

info sharp Downloading https://github.com/lovell/sharp-libvips/releases/download/v8.7.4/libvips-8.7.4-darwin-x64.tar.gz
sh: line 1: 33119 Illegal instruction: 4 prebuild-install

[lovell]

@tommygrealy The 8.7.4 binaries should be OK as-is. What CPU is this with?

[TommyGrealyIntel]

Thanks @lovell - I got it working via the following steps:

(with the libvips-8.7.0-darwin-x64.tar.gz file already stored in ~/.npm/_libvips directory)

1. edit package.json in the node_modules.sharp folder - changed config->libvips 8.7.4 to 8.7.0
2. removed the directory node_modules/sharp/vendor
3. npm rebuild sharp

Now it's working :) Thanks
-Tommy

FYI - CPU is 2.4 GHz Intel Core 2 Duo (this is an OLD mac :) )

[lovell]

@tommygrealy Thanks, I think homebrew defaults to Nehalem as the "oldest" CPU now, so you'll need a CPU with at least support for SSE4.2 intrinsics.