ethon: Segmentation Fault in macOS11 (M1 processor)
Just switched from Ubuntu to Mac OS 11.1 with M1 processor and running rails app that had no issues on Ubuntu.
Running Rspec test suite with typhoeus 1.3.1, ethon 0.12.0, ffi 1.14.2.
/Users/asv/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/ethon-0.12.0/lib/ethon/curls/infos.rb:109: [BUG] Segmentation fault at 0x00000001000653f1 ruby 2.6.6p146 (2020-03-31 revision 67876) [-darwin20]
Offending call seems to be Typhoeus.get(url, opts) where URL is a valid URL and
opts = {:timeout_ms=>6000, :connecttimeout_ms=>3000}
Any idea what may be up?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 21
- Comments: 31 (3 by maintainers)
I seems to fix it by
bundle updatemy issue log:LoadError: dlopen(/Users/userName/.bundle/vendor/ruby/2.6.0/gems/ffi-1.15.0/lib/ffi_c.bundle, 0x0009): tried: '/Users/userName/.bundle/vendor/ruby/2.6.0/gems/ffi-1.15.0/lib/ffi_c.bundle' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/lib/ffi_c.bundle' (no such file) - /Users/mac/.bundle/vendor/ruby/2.6.0/gems/ffi-1.15.0/lib/ffi_c.bundleIssue likely relates to FFI and how FFI works under arm64(e). There seems to be a patch going on in https://github.com/libffi/libffi/pull/620 to add proper support for some of the new safety mechanisms in arm64e to libffi. The general workaround meanwhile seems to be to make sure to use the system libffi by doing
gem install ffi -- --enable-system-libffi, but although this did solve the problem for me for a couple of other FFI related gems, it didn’t solve the problem with ethon and curl at all. While searching for segmentation fault issues on M1 the ethon gem does come up a lot more than others as well so there might still be some underlying issue here, either with this gem, ffi or potentially curl.I have tried to definitely use a custom built curl/ruby the following way as well:
but it was still not working, so this was a dead end at least for now.
Note: if anyone is stuck here one other workaround to at least unblock you is to simply use the rosetta2/intel version of applications until this is sorted long term. You can do that by opening up your terminal in rosetta2 mode and rebuilding / reinstalling ruby and other tools you might need from there to make sure they get compiled in x86_64 mode. While it is annoying and you do get the performance hit it is fortunately negligible and will at least unblock you until there’s a permanent solution
I have a similar (potentially the same) issue, and a dead simple script reproduces it. Fair warning: I’ve been out of the Ruby game for a bit so I didn’t try to make an ethon-only example. Anyway, my simple example here crashes in the same way I was seeing for something deep in a cocoapods command -
easy_getinfowithhttpauth_avail.These particular Ruby installations come from Homebrew, configured for native (arm64) packages. The system Ruby installation is useless here as
ffiwill fail to select appropriate architectures.bug.rb:Ruby 3.0.0
Homebrew formula
rubygem envoutputruby bug.rboutputcrash report
Ruby 2.7.2
Homebrew formula
ruby@2.7gem envoutputruby bug.rboutputcrash report
Ruby 2.6.6
Homebrew formula
ruby@2.6gem envoutputruby bug.rboutputcrash report
I don’t think this issue is totally resolved yet, myself and @silva96 are still experiencing this. M3, MacOS 14.1 (23B2073)
This still fails for me using ethon 0.16.0, @christiannelson how did #180 fix your problem?
Yes, that’s what we had to do, run zsh itself in rosetta mode and then install everything from here, so everything (rbenv, ruby, homebrew, curl, etc) is x86_64 and not arm64.
Meanwhile I’m trying to build everything from scratch in amd mode, including the ffi changes that has been pushed to see if that solves the problem, I’ll keep you posted
I spent a couple hours yesterday trying to debug this issue. With the test suite, many of the tests pass– including things like calls to
versionvia FFI.However,
easy_performandeasy_setopt_ffipointercause a segfault with the result: https://gist.github.com/hcatlin/ff0980d983990322e102775f16e42030And here is the DiagnosticLog too
ruby_2021-02-09-130931_Hamptons-MacBook-Air.txt
The highlight being that it’s a EXC_BAD_ACCESS (SIGABRT)
I can confirm this issue… Typheous hard crashes on my arm64 mac.