Segmentation Fault in macOS11 (M1 processor) #172
Comments
|
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 - These particular Ruby installations come from Homebrew, configured for native (arm64) packages. The system Ruby installation is useless here as
require "typhoeus"
Typhoeus::get("https://github.com/")Ruby 3.0.0Homebrew formula
|
|
I can confirm this issue... Typheous hard crashes on my arm64 mac. |
|
same issue |
|
same issue, had to switch to other adapters as a workaround for now |
|
Can confirm the problem. By the way, are there any updates or news on this issue? |
|
Same, +1. |
|
@mengqing Could you please share the workaround for us? Thanks. |
I believe what he meant is that they just moved to using another library for now, e.g. Curb, which is also what we are gonna do. |
Yes that is correct. We use typhoeus as faraday adapter, and as a workaround, I'm switching to faraday default adapter (on my local) until this issue is fixed |
|
would it be possible to build ethon against brew installed libcurl instead of system provided curl? brew reinstall curl log mentioning compilers to find curl you may need to set |
|
Seeing the same issue on a fresh M1 Macbook. |
|
Same issue on MAC with M1 processor |
|
Same issue on M1 Macbook |
Merged
|
I just moved from Travis to Github Actions and added macos as test-platform as well but all tests have passed so I am currently unable to reproduce the issue as I do not have a Macbook to test it. But the stack trace shows PS: I scrolled through the issue list saw a lot of segfaults on macOS every few years with no clear solution right now. All of them seem to be an issue of the libcurl version though and are not directly related to this gem. |
|
Another update/note - please check if this is issue also occurs with the master branch. |
|
@Kjarrigan Thanks for looking in to this. I believe the issue is not a macOS, but macOS running on Apple's new M1 CPU/SoC. Github Actions do not yet support the M1 as a platform (see actions/runner-images#2187). So, it's no surprise to me that macOS is passing. On M1 hardware, running under the Rosetta 2 emulator, everything works for me. On M1 hardware, running native ruby, gems, etc (whole runtime stack), I see this issue consistently. I switched to ethon master and still see the issue. I believe by default, ethon is using the version of libcurl that ships with macOS. I tried installing curl (and libcurl) via homebrew, and still see the same error. This may be helpful? Happy to do some other testing if you'd like. -Christian |
|
Now that I look at that console output, I see something fishy. I followed the instructions provided by But I still have the same issue. :( |
|
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 However, And 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) |
Thanks both of you for providing additional information. I'll look through them soon-ish and will hopefully find something 🤞 |
In a nutshell, Apple is moving away from Intel CPUs over a 2 year period starting last November. All of their computers will be using CPUs (which are really SoCs -- systems on a chip) they have designed and are very similar to the SoCs in iPhones and iPads. The new CPUs/SoCs are called "Apple Silicon" and the first model is the "M1". Apple Silicon is an enhanced ARM architecture. It's extremely fast for its power demands and thermal profile, which ultimately means faster, much cooler running, and better battery life. Apple expects everything to run natively on Apple Silicon/M1 eventually, but has created an emulator called Rosetta 2 which allows M1 Macs to run Intel binaries. Rosetta works very well, but has overhead. So, we're in a bit of a weird period where we wait for native M1 builds of everything and some issues related to the M1 must be resolved, like this issue. |
|
I am running into this exact bug on M1 Mac, and I am running the exact same specs as OP |
|
Issue likely relates to FFI and how FFI works under arm64(e). There seems to be a patch going on in libffi/libffi#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 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 pretty much the same situation, installation of
The problem with this approach is that there seems to be no realiable way to run everything through rosetta. |
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 |
|
One interesting note that I have tried building our app under Ubuntu running in QEMU under the M1, and for some reason the ethon gem died there with a segmentation fault as well at the same place. Haven't investigated it further yet, so I'm not sure if this is a bug with QEMU on M1, ethon on M1, or maybe with ethon on ARM64 architectures in general. I'm going to check if this fails on a non-M1 ARM64 machine and if yes the issue is probably there Update on this: The issues were actually related to the build infrastructure. Ethon actually works just fine under a VM under Ubuntu on the M1 using the latest version of the ffi gem and libffi library Second update: I have also tried to use an ffi gem that was explicitly built against this PR from the libffi git: libffi/libffi#621 . While on ruby 2.6.6 this has still resulted in the same segmentation faults, under ruby 2.7.2 using the libffi code above did somewhat decrease the number of issues that I faced (compared to using ffi 1.14.2). However the issues didn't disappear, random segfaults are still appearing with that version as well |
|
I see this issue has been closed, but I think I missed the resolution. FWIW, I'm still seeing the same issue after ensuring that I'm using the latest versions of all gems. What did I miss? |
|
Whoops, I missed the reference to #180. I see it now... thanks! |
|
I seems to fix it by |
|
Thanks @FrizzleFur, that put me on the right track. |
|
This still fails for me using ethon 0.16.0, @christiannelson how did #180 fix your problem? |
|
I don't think this issue is totally resolved yet, myself and @silva96 are still experiencing this. |
|
I am experiencing same issue. Ruby: 3.2.3 Trace: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
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 andopts =
{:timeout_ms=>6000, :connecttimeout_ms=>3000}Any idea what may be up?
The text was updated successfully, but these errors were encountered: